Something needs to happen with shared, and soon.

Sean Kelly sean at invisibleduck.org
Thu Nov 15 16:23:59 PST 2012


On Nov 15, 2012, at 3:30 PM, David Nadlinger <see at klickverbot.at> wrote:

> On Thursday, 15 November 2012 at 23:22:32 UTC, Sean Kelly wrote:
>> On Nov 15, 2012, at 3:05 PM, David Nadlinger <see at klickverbot.at> wrote:
>>> Well, to be picky, that depends on what kind of memory operation you mean – moving non-volatile loads/stores across volatile ones is typically considered acceptable.
>> 
>> Usually not, really.  Like if you implement a mutex, you don't want non-volatile operations to be hoisted above the mutex acquire or sunk below the mutex release.  However, it's safe to move additional operations into the block where the mutex is held.
> 
> Oh well, I was just being stupid when typing up my response: What I meant to say is that you _can_ reorder a set of memory operations involving atomic/volatile ones unless you violate the guarantees of the chosen memory order option.
> 
> So, for Andrei's statement to be true, shared needs to be defined as making all memory operations sequentially consistent. Walter doesn't seem to think this is the way to go, at least if that is what he is referring to as »memory barriers«.

I think because of the as-if rule, the compiler can continue to optimize all it wants between volatile operations.  Just not across them.


More information about the Digitalmars-d mailing list