digitalmars.D - Status of D and Concurrency
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
Jul 17 2011
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.
Jul 17 2011