== Quote from Walter Bright ([email protected])'s article > 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.
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?
