From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-12-01 07:46:47
Anthony Williams wrote:
> Roland Schwarz <roland.schwarz_at_[hidden]> writes:
>> In particular in
>> presence of multiple processors. I.e. an atomic lib is primarily about
>> performance.
>
> Not just about performance. It also enables the construction of the
> higher-level primitives.
As you might know, this was the route I am following. But the primitives
are not necessarily exposed to the user. To be more precise: From a user
perspective an atomic lib is primarily about performance. Better?
> I think that the memory barrier and acquire/release semantics are just two
> ways of talking about the same thing.
This is a point where I am still confused about. acquire/release are
"one way" ordering constraints while memory barriers are "both way".
This is as I understand it:
*) memory barriers are primitives which have no other effect as to
order memory access, i.e. they do not store or load anything by themselves.
Also they affect only memory operations and have no effect on others.
Also they should affect the compiler, as to disallow reordering across
the barrier.
There are 3: read_mb, write_mb and full_mb.
read_mb.
read_mb orders read access, i.e. no read from before may be moved after
the barrier and no read from after may be moved before the barrier.
write_mb does the same for writes. full_mb disallows moving any read or
write across the barrier, and so establishes total order.
*) acquire/release semantics on the other hand establish a
conceptional different model of ordering. acquire disallows moving any
access (read/write) from after the primitive to occur before it, but
still allows accesses from before to occur after it. This is kind of a
one-way sign for accesses.
release semantics is the other way round.
Also acquire/release is bound to an operation kind of an attribute of
the operation, while memory barriers are operations on their own.
So as I currently understand it, these two concepts are about the same
issue, but are neither orthogonal nor can one be used to synthesize the
other. I would be glad to be proved wrong.
Another observation: release/acquire semantics is closer to mutex
behavior, since no harm is done when an operation from before mutex
acquisition is moved inside the critical section. A barrier would not
allow such an operation. True?
> As I understand it, on x86, the SFENCE instruction is a "Store Fence", which
> is a "Write Barrier", and has "Release Semantics". Any store instructions
> which happen before it on this CPU are made globally visible afterwards. No
> stores instructions which occur afterwards on this CPU are permitted to be
> globally visible beforehand.
This looks to me as it is possible in the acquire/release model to
separate the operation from the "fence". Or viewed in the other
direction, it is possible to optimize by attaching the (otherwise
separate) fence to a instruction to save some cpu cycles. True?
> Again on x86, the LFENCE instruction is a "Load Fence", which is a "Read
> Barrier", and has "Acquire Semantics". Any read instructions which happen
> before it on this CPU must have already completed afterwards.
Are you really sure about this one?
> No loads
> instructions which occur afterwards on this CPU are permitted to be executed
> beforehand.
This part of the statement makes sense to me.
I omitted the rest of your post, since I think it depends on the
acquire/release versus memory barriers getting clarified first.
> The details of the memory model, atomics, and visibility, and how it applies
> to C++, are under discussion amongst C++ standards committee members. I would
> imagine that you'd be welcome to join such discussions.
Hmm, not sure how I could join other than posting to some lists. Do you
mean comp.lang.c++.moderated?
Roland