svn commit: r238907 - projects/calloutng/sys/kern

[David Chisnall]

On 18 Sep 2012, at 11:53, Konstantin Belousov wrote:

> How can atomic_SIGNAL_fence be even remotely conceptually right for the
> kernel execution environment ? The fact that current implementation
> happens to offer similar guarantees is a coincidense.

atomic_signal_fence() is a barrier that enforces ordering with respect to memory accesses within the same thread, but in the presence of asynchronous events.  The fact that it contains the word signal is irrelevant.  You may substitute interrupt for signal when reading it if it makes you happier.

> Agreed, but you did not looked at atomic.h. The memory clobbering is
> only performed for atomics which do not need asm. The load acquire and
> store release are implemented as the normal load and stores on x86, due
> to existing architecture guarantees.

Ah, that makes sense, although, again, we have too strong a requirement here.  With a signal fence with an explicit acquire or release memory ordering (or, better, an atomic_load_explicit() / atomic_store_explicit() with an associated barrier), on x86 we will get the single load or store instruction, and the compiler will be free to reorder instructions except where doing so would conflict with the barrier semantics.

> Exactly which atomic operations for x86 do you reference there ?
> Are you aware about e.g. AMD recommendations for the barrier/lock
> prefix use (look into atomic.h) ?

All of the operations that require inline assembly are, from the perspective of the compiler, full barriers.  They do not need to be preventing reordering with respect to operations that do not touch memory.  Similarly, where we have acquire or release barriers, the compiler should be free to either reorder stores or loads in one direction across the barrier, but is prevented from doing so by the memory clobber.  

David