RE: Synchronizing Bit operations V2

[Christoph Lameter <clameter@sgi.com>]

On Thu, 30 Mar 2006, Chen, Kenneth W wrote:

> > What of it? Release semantics are not a full fence or memory barrier.
> 
> The API did not require a full fence.  It is defined as a one way fence.

Well that explains our misunderstanding.

The issue with all these hacky macros is that they all have their own 
semantics and do not work in a consistent way. More reason to make that 
explicit.

Where may I find that definition?

Documentation/atomic_ops.txt implies a complete barrier and gives
an example of the use of these macros in order to obtain release 
semantics. AFAIK that does not mean that this is the intended complete 
behavior of a "memory barrier":




If a caller requires memory barrier semantics around an atomic_t
operation which does not return a value, a set of interfaces are
defined which accomplish this:

        void smp_mb__before_atomic_dec(void);
        void smp_mb__after_atomic_dec(void);
        void smp_mb__before_atomic_inc(void);
        void smp_mb__after_atomic_dec(void);

For example, smp_mb__before_atomic_dec() can be used like so:

        obj->dead = 1;
        smp_mb__before_atomic_dec();
        atomic_dec(&obj->ref_count);

It makes sure that all memory operations preceeding the atomic_dec()
call are strongly ordered with respect to the atomic counter
operation.  In the above example, it guarentees that the assignment of
"1" to obj->dead will be globally visible to other cpus before the
atomic counter decrement.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/