Something needs to happen with shared, and soon.

[Andrei Alexandrescu]

On 11/13/12 2:22 PM, Walter Bright wrote:
> On 11/13/2012 1:56 PM, Andrei Alexandrescu wrote:
>> On 11/13/12 1:28 PM, Walter Bright wrote:
>>> On 11/13/2012 1:11 AM, luka8088 wrote:
>>>> This clarifies a lot, but still a lot of people get confused with:
>>>> http://dlang.org/faq.html#shared_memory_barriers
>>>> is it a faq error ?
>>>
>>> Andrei is a proponent of having shared to memory barriers, I disagree
>>> with him. We haven't convinced each other yet, so this is a bit up in
>>> the air.
>>
>> Wait, then what would shared do? This is new to me as I've always
>> assumed you
>> and I have the same view on this.
>
> I'm just not convinced that having the compiler add memory barriers:
>
> 1. will result in correctly working code, when done by programmers who
> have only an incomplete understanding of memory barriers, which would be
> about 99.9% of us.
>
> 2. will result in efficient code

I'm fine with these arguments. We'll need to break current uses of 
shared then. What you say is that essentially you can't do even this:

shared int x;
...
x = 4;

You'll need to use x.load(4) instead.

Just for the record I'm okay with this breakage.

> I also worry that it will lure programmers into a false sense of
> complacency about shared, that simply adding "shared" to a type will
> make their concurrent code work. Few seem to realize that adding memory
> barriers only makes code sequentially consistent, it does *not*
> eliminate race conditions.

It does eliminate all low-level races.

> It just turns a multicore machine into
> (logically) a single core one, *not* a single threaded one.

This is very approximate.

> But I do see enormous value in shared in that it logically (and rather
> forcefully) separates thread-local code from multi-thread code. For
> example, see the post here about adding a destructor to a shared struct,
> and having it fail to compile. The complaint was along the lines of
> shared being broken, whereas I viewed it along the lines of shared
> pointing out a logic problem in the code - what does destroying a struct
> accessible from multiple threads mean? I think it must be clear that
> destroying an object can only happen in one thread, i.e. the object must
> become thread local in order to be destroyed.

As long as a cast is required along the way, we can't claim victory. I 
need to think about that scenario.


Andrei