Status of D and Concurrency

[dsimcha]

On 7/17/2011 8:55 PM, Ameer Armaly wrote:
> Hi all. Some of you might remember me from this news group some five or six years ago; since then I've been doing mostly Java but I've had my eye on D for a new project I'm contemplating. It appears that D 2 has settled compared to
> its former state of flux and that the standard library situation has also settled somewhat.
> The main thing I'm looking for and don't see right now is out-of-box work queue and concurrent collections support.

Concurrent collections don't exist anywhere in Phobos yet.  If you only 
need one or two specific types of collection, I may be able to offer 
suggestions for an easy workaround.  Also, in most simple cases it would 
be easy to create a shared wrapper around an unshared collection that 
just synchronizes on every method call.  This can be made even simpler 
with opDispatch 
(http://www.d-programming-language.org/operatoroverloading.html#Dispatch).

Currently there are three options in Phobos/druntime for multithreading:

1.  std.concurrency 
(http://www.d-programming-language.org/phobos/std_concurrency.html) 
provides a message passing system and is geared towards general-case, 
coarse grained concurrency.  Its design philosophy is safe and simple 
first, flexible second.  All mutable data not explicitly marked as 
shared is local to a single thread.  All access to shared data is 
guaranteed to be free from low-level data races (I think this might 
still be buggy) but you're on your own when it comes to high-level 
invariants.  This is the model described in the last chapter of Andrei 
Alexandrescu's book.  (This chapter is available for free at 
http://www.informit.com/articles/printerfriendly.aspx?p=1609144 .)

2.  std.parallelism 
(http://www.d-programming-language.org/phobos/std_parallelism.html) is 
probably the most like Java's concurrent utilities.  It provides 
multithreading tools geared towards parallel processing, including tasks 
(which can be executed by the TaskPool class, which uses a work queue 
internally), parallel foreach, parallel map and parallel reduce.  Its 
design philosophy is to be simple and flexible first, and provide as 
much safety as possible without compromising simplicity and flexibility. 
  Most idiomatic uses of std.parallelism split up work in a way that 
avoids the need for any explicit synchronization.  The synchronization 
is done under the hood as part of the high-level primitives 
std.parallelism provides.

3.  core.thread is a low-level wrapper over operating system concurrency 
APIs.  It's good for implementing higher level paradigms and both 
std.parallelism and std.concurrency use it internally, but it's far too 
low-level for day-to-day use.