Something needs to happen with shared, and soon.

Walter Bright newshound2 at digitalmars.com
Tue Nov 13 14:22:07 PST 2012


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 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 just turns 
a multicore machine into (logically) a single core one, *not* a single threaded one.

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.





More information about the Digitalmars-d mailing list