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.
