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
a...@lycus.org
http://lycus.org
