Something needs to happen with shared, and soon.

[Walter Bright]

On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:
> It's starting to get outright embarrassing to talk to newcomers about D's
> concurrency support because the most fundamental part of it -- the shared type
> qualifier -- does not have well-defined semantics at all.

I think a couple things are clear:

1. Slapping shared on a type is never going to make algorithms on that type work 
in a concurrent context, regardless of what is done with memory barriers. Memory 
barriers ensure sequential consistency, they do nothing for race conditions that 
are sequentially consistent. Remember, single core CPUs are all sequentially 
consistent, and still have major concurrency problems. This also means that 
having templates accept shared(T) as arguments and have them magically generate 
correct concurrent code is a pipe dream.

2. The idea of shared adding memory barriers for access is not going to ever 
work. Adding barriers has to be done by someone who knows what they're doing for 
that particular use case, and the compiler inserting them is not going to 
substitute.


However, and this is a big however, having shared as compiler-enforced 
self-documentation is immensely useful. It flags where and when data is being 
shared. So, your algorithm won't compile when you pass it a shared type? That is 
because it is NEVER GOING TO WORK with a shared type. At least you get a compile 
time indication of this, rather than random runtime corruption.

To make a shared type work in an algorithm, you have to:

1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex

Also, all op= need to be disabled for shared types.