On Friday, August 12, 2016 16:38:23 Kagamin via Digitalmars-d wrote: > On Friday, 12 August 2016 at 15:43:54 UTC, Steven Schveighoffer > > wrote: > > All kidding aside, shared is pretty broken currently. If you > > want to know how it was *supposed* to work, you can read TDPL, > > though I'm not sure that's still valid. > > Ah, was it Andrei, who tried to sell the idea that shared is a > silver bullet for concurrency problems? That can explain why we > have two different views on shared. Looks like a repetition of > the story with autodecoding (with similar rationale).
Honestly, I don't think that shared is broken. It's just that once you've locked the appropriate mutex, you have to cast a way shared and make sure that no thread-local references to that data are still around when you release the lock. shared is doing its job of indicating when a variable isn't thread-local as well as preventing a number of incorrect operations on data that's shared across threads without being protected by a lock. What we're missing is a way safely have shared cast away for us so that we don't have to do the work of verifying that we're not screwing it up. synchronized classes as described in TDPL partially solve the problem in that they provide a safe, automatic way to remove one layer of shared - but it's only one layer, and it's never been implemented. It's the equivalent of having a set of operations that we'd like to be @safe but are stuck as @system, and we're forced to use @trusted to deal with it. But folks get annoyed with shared, because they have to cast it away at the appropriate time. They just want it to magically work in a safe manner, and we simply haven't figured out how to do that. Instead, we have a way to segregate shared stuff and thus minimize how much code has to deal with the problems that come with sharing data across threads but which requires that you handle it carefully rather than having a way to just handle it safely, automatically. shared isn't perfect, but having thread-local by default is dowright fantastic, and when you have to deal with shared, you mostly doing the same sorts of things that you're supposed to be doing in C++. It's just that you have to cast away shared to operate on the object while the mutex is locked. IMHO, the biggest problem with shared is that the related types in druntime (like the mutexes and condition variables) aren't marked with it properly rather than shared itself being fundamentally flawed. - Jonathan M Davis