Marcel Müller
6/18/2014 9:32:00 PM
On 18.06.14 08.38, Toby Douglass wrote:
> First, when I issue a store barrier, will the processor stall at that
> point until its store buffers are flushed, or will it actually proceed
> and rather than stalling, simply honour the ordering constraint
> specified by the presence of the store barrier by ensuring later stores
> will occur and only occur *after* all stores prior to the store barrier?
> e.g. there is no guarantee *when* the stores occur (they are not forced
> to occur at the time of the barrier), only that those prior to the
> barrier occur before those after the barrier.
That's it, but in fact it is implementation dependent. However, there is
no difference. If no information can leave the CPU in different order it
is impossible to distinguish from outside whether the CPU has already
come to this point or not.
> Second, if I issue an atomic operation (XCHG, say), will this force a
> write to memory and as such if (for example) immediately preceded by a
> store barrier (compulsory on Intel, not so on ARM) *force the flushing
> of store buffers by dint of the fact a write to memory really is now
> going to happen because that's what atomic operations do*.
AFAIK there is no such guarantee that any atomic operation implies a
full membar. It is also implementation dependent.
But on x86/x64 there is no memory reordering. So all discussion about
memory barriers are meaningless there. The usual guarantee is that
acquiring a mutex implies a full membar. But not that this has to be
done by a single machine instruction.
Marcel