On Tuesday, 14 February 2017 at 14:27:05 UTC, Kagamin wrote:
On Monday, 13 February 2017 at 17:44:10 UTC, Moritz Maxeiner
wrote:
To be clear: While I might, in general, agree that using
shared methods only for thread safe methods seems to be a
sensible restriction, neither language nor compiler require it
to be so; and absence of evidence of a useful application is
not evidence of absence.
Right, a private shared method can be a good use case for a
thread-unsafe shared method.
---
__gshared int f = 0, x = 0;
Object monitor;
// thread 1
synchronized (monitor) while (f == 0);
// Memory barrier required here
synchronized (monitor) writeln(x)
// thread 2
synchronized (monitor) x = 42;
// Memory barrier required here
synchronized (monitor) f = 1;
---
Not sure about this example, it demonstrates a deadlock.
That's beside the point, but I guess I should've clarified the
"not needed" as "harmful". The point was that memory barriers and
synchronization are two separate solutions for two separate
problems and your post scriptum about memory barriers disregards
that synchronization does not apply to the problem memory
barriers solve.
On Tuesday, 14 February 2017 at 14:27:05 UTC, Kagamin wrote:
My opinion on the matter of `shared` emitting memory barriers
is that either the spec and documentation[1] should be updated
to reflect that sequential consistency is a non-goal of
`shared` (and if that is decided this should be accompanied by
an example of how to add memory barriers yourself), or it
should be implemented.
I'm looking at this in terms of practical consequences and
useful language features.
So am I.
On Tuesday, 14 February 2017 at 14:27:05 UTC, Kagamin wrote:
What people are supposed to think and do when they see
"guarantees sequential consistency"? I mean people at large.
That's a documentation issue, however, and is imho not relevant
to the decision whether one should, or should not emit memory
barriers. It's only relevant to how the decision is then
presented to the people at large.
On Tuesday, 14 February 2017 at 14:27:05 UTC, Kagamin wrote:
I agree, message passing is considerably less tricky and
you're unlikely to shoot yourself in the foot. Nonetheless,
there are valid use cases where the overhead of MP may not be
acceptable.
Performance was a reason to not provide barriers. People, who
are concerned with performance, are even unhappy with virtual
methods, they won't be happy with barriers on every memory
access.
You seem to be trying to argue against someone stating memory
barriers should be emitted automatically, though I don't know why
you think that's me; You initially stated that
Memory barriers are a bad idea because they don't defend from a
race condition, but they look like they do
which I rebutted since memory barriers have nothing to do with
race conditions. Whether memory barriers should automatically
emitted by the compiler is a separate issue, one on which my
position btw is that they shouldn't. The current documentation of
`shared`, however, implies that such an emission (and the related
sequential consistency) is a goal of `shared` (and just not -
yet? - implemented) and does not reflect the apparently final
decision that it's not.
