OT: In a language far, far away. (Was: Re: Bartosz Milewski Missing post)

Daniel Keep daniel.keep.lists at gmail.com
Thu May 28 15:06:44 PDT 2009



Andrei Alexandrescu wrote:
> BCS wrote:
>> ...
>>
>> Am I wrong in assuming that most languages use user mode (not kernel
>> mode) shared memory for inter thread communication?
> 
> What happens is that memory is less shared as cache hierarchies go
> deeper. It was a great model when there were a couple of processors
> hitting on the same memory because it was close to reality. Cache
> hierarchies reveal the hard reality that memory is shared to a
> decreasing extent and that each processor would rather deal with its own
> memory. Incidentally, message-passing-style protocols are prevalent in
> such architectures even at low level. It follows that message passing is
> not only an attractive model for programming at large, but also a model
> that's closer to machine than memory sharing.

This is all very interesting.  I've recently been playing with a little
toy language I'm designing.  It's a postfix language, so I'm fairly
certain no one will ever want to even look at it.  :P

But when I was designing it, I was adamant that it should do safe
parallelism.  I worked out that I could get everything other than
deadlock safety by giving everything value semantics (using
copy-on-write for anything larger than an atomic value.)  Add in
references that remember their "owner" thread and can only be
dereferenced by that single thread, and then note that the global dict
and stack are just values themselves and hence copied not referenced
when you create a new thread.

The only method of communication between threads is using message
channels.  This could be quite slow if you try to pass a very large data
structure (since everything always gets copied), so you can create it on
the heap via a reference, then "disown" the reference and assign it to
another thread.  That way you can get the efficiency of
pass-by-reference without inter-thread aliasing.

I also have a plan for making the language deadlock-free by either
re-expressing all locks as blocking messages such that the interpreter
knows who is blocking who, or by going all-out and just using transactions.

But this is all just me stuffing about with a completely impractical
language.  What's being done for D is much more interesting.  :)



More information about the Digitalmars-d mailing list