• Ameer Armaly (8/8) Jul 17 2011 Hi all. Some of you might remember me from this news group some five or ...
• dsimcha (36/39) Jul 17 2011 Concurrent collections don't exist anywhere in Phobos yet. If you only

Ameer Armaly <ameer_armaly hotmail.com> writes:

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. If this can be accomplished easily I'd love
to know how (think of Java's concurrency infrastructure to get an idea
what I'm looking for). If it can't I'd like to do something to make it
workable; it would be nice to know what has been implemented, what needs to be
implemented, and any conventions/protocols that have been put in place.
On a somewhat related note: I was looking through the language spec and didn't
see any information on what exactly 'shared' does. If I had to guess I'd say it
was supposed to guarantee some degree of atomicity which would be
particularly useful to me but I don't see that spelled out anywhere.
Any help you guys can provide would be greatly appreciated. It's nice to be
back.

Ameer

dsimcha <dsimcha yahoo.com> writes:

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.