Something needs to happen with shared, and soon.

deadalnix deadalnix at gmail.com
Tue Nov 13 16:04:55 PST 2012


Le 13/11/2012 23:22, Walter Bright a écrit :
> 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.
>

That is what java's volatile do. It have several uses cases, including 
valid double check locking (It has to be noted that this idiom is used 
incorrectly in druntime ATM, which proves both its usefullness and that 
it require language support) and disruptor which I wanted to implement 
for message passing in D but couldn't because of lack of support at the 
time.

See: http://www.slideshare.net/trishagee/introduction-to-the-disruptor

So sequentially consistent read/write are usefull.

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

This struct stuff don't make any sense to me. Java, C# and many other 
language multithread, have everything shared and still are able to have 
finalizer of some sort.

Why couldn't a shared object be destroyed ? Why should it be destroyed 
in a specific thread as it can only refer shared data because of 
transitivity ?


More information about the Digitalmars-d mailing list