dsimcha wrote:
== Quote from Walter Bright ([email protected])'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.
