Am Tue, 14 Feb 2017 13:01:44 +0000 schrieb Moritz Maxeiner <mor...@ucworks.org>: > > It's not supposed to. Also, your example does not implement the > same semantics as what I posted and yes, in your example, there's > no need for memory barriers. In the example I posted, > synchronization is not necessary, memory barriers are (and since > synchronization is likely to have a significantly higher runtime > cost than memory barriers, why would you want to, even if it were > possible). >
I'll probably have to look up about memory barriers again, I never really understood when they are necessary ;-) > > > > I remember some discussions about this some years ago and IIRC > > the final decision was that the compiler will not magically > > insert any barriers for shared variables. Instead we have > > well-defined intrinsics in std.atomic dealing with this. Of > > course most of this stuff isn't implemented (no shared support > > in core.sync). > > > > -- Johannes > > Good to know, thanks, I seem to have missed that final decision. > If that was indeed the case, then that should be reflected in the > documentation of `shared` (including the FAQ). https://github.com/dlang/dlang.org/pull/1570 I think it's probably somewhere in this thread: http://forum.dlang.org/post/k7pn19$bre$1...@digitalmars.com >1. Slapping shared on a type is never going to make algorithms on that >type work in a concurrent context, regardless of what is done with >memory barriers. Memory barriers ensure sequential consistency, they >do nothing for race conditions that are sequentially consistent. >Remember, single core CPUs are all sequentially consistent, and still >have major concurrency problems. This also means that having templates >accept shared(T) as arguments and have them magically generate correct >concurrent code is a pipe dream. > >2. The idea of shared adding memory barriers for access is not going >to ever work. Adding barriers has to be done by someone who knows what >they're doing for that particular use case, and the compiler inserting >them is not going to substitute. > >However, and this is a big however, having shared as compiler-enforced >self-documentation is immensely useful. It flags where and when data >is being shared. http://forum.dlang.org/post/mailman.1904.1352922666.5162.digitalmar...@puremagic.com > Most of the reason for this was that I didn't like the old > implications of shared, which was that shared methods would at some > time in the future end up with memory barriers all over the place. > That's been dropped, [...] -- Johannes