Mallocator and 'shared'

[Kagamin via Digitalmars-d-learn]

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.