Mallocator and 'shared'

[Moritz Maxeiner via Digitalmars-d-learn]

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.