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.
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. What people are supposed to think and do when
they see "guarantees sequential consistency"? I mean people at
large.
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.
