Concurrency architecture for D2

dsimcha dsimcha at yahoo.com
Fri Jan 8 17:45:39 PST 2010


== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> dsimcha wrote:
> > == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> >> Sure. Except that implicit parallelism is inherently unsound unless the
> >> type system can support it.
> >> I'll go further than that. Any language that supports implicit sharing
> >> of mutable data is inherently unsound for multithreaded programming.
> >
> > One thing that I think needs to be considered in the concurrency architecture is
> > the case of performance-critical massive data parallelism.  In these cases
> > concurrency is actually not very hard and a simple parallel foreach loop covers a
> > lot of cases.  As far as safety, the amount of code being executed inside a
> > parallel foreach loop is generally small enough that it's easy to reason about,
> > and thus it's ok not to have any hard static guarantees and leave safety up to the
> > programmer, as long as the programmer understands at least the basics of
concurrency.
> It's hard to reason about even small examples. Consider the double
> checked locking bug. I even thought I understood it, until Bartosz
> discovered I'd written one into Phobos.
> As for understanding the basics of concurrency, I defy anyone to read
> the Intel CPU manuals and discover how memory read/write barriers work
> on Intel chips and how and when they should be used.
> With C++, everyone using memory barriers has to figure it out, and the
> consequences of getting it wrong are very, very, very obscure bugs. With
> D, only the compiler writer has to get it right.
> > I would like to see a situation where OpenMP/ParallelFuture-style concurrency is
> > still implementable in D without unreasonable performance or syntactic overhead
> > after the new concurrency system is fully in place.
> There's no reason it cannot be.
> At the worst, you can cast away "shared" and cowboy it exactly as you
> would in C++.
> There is no circumstance where you are worse off with D than with C++,
> and quite a lot of cases where you're much better off.

Ok, one thing that leads to a lot of misunderstanding and confusion is that
there's (as far as I can tell) absolutely no documentation of what shared
does/will do or what its semantics are/will be, other than a few newsgroup posts
from years ago,which were tentative, and the "migrating to shared" article, which
is mostly about thread-local storage.  Also, as far as I can tell, shared is not
fully implemented yet, because core.thread doesn't require a shared delegate.  Is
this correct?

Here are some questions, and this is just what I've been able to think of off the
top of my head in a few minutes:

What guarantees is shared supposed to provide?
What does shared have to do with synchronization?
What does shared have to do with memory barriers?
What are the semantics of casting FROM unshared TO shared?
What are the semantics of casting FROM shared TO unshared?
Why doesn't shared appear anywhere in core.thread?



More information about the Digitalmars-d mailing list