Something needs to happen with shared, and soon.

[Alex Rønne Petersen]

On 13-11-2012 23:33, Andrei Alexandrescu wrote:
> 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.

Is that meant to be an atomic store, or just a regular, but explicit, store?

(I know you meant store.)

>
> 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


-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org