RE: Synchronizing Bit operations V2

["Chen, Kenneth W" <kenneth.w.chen@intel.com>]

Christoph Lameter wrote on Thursday, March 30, 2006 7:21 PM
> > > 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.

It means we need an complete overhaul of smp_mb__before/after_*.  The name
and its implied memory order semantics is not consistent and it leads to all
kinds of confusion and probably improper usage.

I'm all for making atomic bit op to have explicit ordering mode in them.

- Ken