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. - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |