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.
