Concurrency architecture for D2

[Walter Bright]

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.