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

[Konstantin Belousov]

Can you finally fix your MUA ?

On Tue, Sep 18, 2012 at 01:15:01PM +0100, David Chisnall wrote:
> 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.
The standard (or rather, my copy of the committee draft from april 2011)
is absolutely unambiguous there, it only talks about signal handlers.

> 
> > 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.

So it is down to allow the compiler to move operations.

> 
> > 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.  

Again, this is down to the compiler' move of operations.

I think that we might find a use there for operations like
__atomic_compiler_{acq,rel} which would inform the compiler about
allowed moves.

And no, use of stdatomic.h in or instead of atomic.h cannot be an option.
First, stdatomic.h presence is not required for freestanding environment.
Second, implementation is allowed to block to guarantee atomicity
(with lock free testing functions and related horror). So std conformance
is complete moot for our use of atomic.h.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20120918/5b763122/attachment.pgp