The future of concurrent programming

[Sean Kelly]

David B. Held wrote:
> Sean Kelly wrote:
>> [...]
>> Sorry, I misundertood.  For some reason I thought you were saying 
>> Apache could scale to thousands of threads.  In any case, D has 
>> something roughly akin to Erlang's thread with Mikola Lysenko's 
>> StackThreads and Tango's Fibers.
> 
> 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.

However, if the task is "fire and forget" then preemption is a clear 
win, since that eliminates the need for mutexes, while cooperation still 
requires yielding.

I like that Sun's pthread implementation in Solaris will spawn both user 
and kernel threads based on the number of CPUs available.  It saves the 
programmer from having to think too much about it, and guarantees a 
decent distribution of load across available resources.  I'm not aware 
of any other OS that does this though.


Sean