The future of concurrent programming

[Brad Anderson]

eao197 wrote:
> On Wed, 30 May 2007 18:01:26 +0400, Sean Kelly <sean at f4.ca> wrote:
> 
>>>  Erlang's threads are better than fibers because they are
>>> pre-emptive. However, this is only possible because Erlang runs on a
>>> VM. Context-switching in the VM is much cheaper than in the CPU
>>> (ironically enough), which means that D isn't going to get near
>>> Erlang's threads except on a VM that supports it (somehow I doubt the
>>> JVM or CLR come close).
>>>  Fibers are nice when you don't need pre-emption, but having to think
>>> about pre-emption makes the parallelism intrude on your
>>> problem-solving, which is what we would like to avoid.
>>
>> If I understand you correctly, I don't think either are a clear win.
>> Preemptive multithreading, be it in a single kernel thread or in
>> multiple kernel threads, require mutexes to protect shared data.
>> Cooperative multithreading does not, but requires explicit yielding
>> instead.  So it's mostly a choice between deadlocks and starvation.
> 
> AFAIK, there isn't shared data in Erlang -- processes in Erlang VM
> (threads in D) communicate each to another by sending and receiving
> messages. And message passing mechanism is very efficient in Erlang VM.

This is true, for the most part.  However, you can have shared data among
Erlang processes.  Mnesia, the distributed database system (in-memory,
on-disk, or both) that ships with Erlang, is an example of an app that allows
shared data.  It's fairly battle-tested in regards to locking, dirty
reads/writes, etc.

BA