22.08.2013, 05:04, "Waiman Long"<waiman.long@xxxxxx>:On 08/21/2013 11:51 AM, Alexander Fyodorov wrote:The thing is that x86 ticket spinlock code does have full memory barriers both in lock() and unlock() code: "add" instruction there has "lock" prefix which implies a full memory barrier. So it is better to use smp_mb() and let each architecture define it.
In this case, we should have smp_wmb() before freeing the lock. The
question is whether we need to do a full mb() instead. The x86 ticket
spinlock unlock code is just a regular add instruction except for some
exotic processors. So it is a compiler barrier but not really a memory
fence. However, we may need to do a full memory fence for some other
processors.
At this point, I am inclined to have either a smp_wmb() or smp_mb() atThat is impossible: both lock() and unlock() must have either full memory barrier or an atomic operation which returns value. Both of them prohibit optimizations and compiler cannot reuse any global variable. So this usage of ACCESS_ONCE() is unneeded.
the beginning of the unlock function and a barrier() at the end.
As the lock/unlock functions can be inlined, it is possible that a
memory variable can be accessed earlier in the calling function and the
stale copy may be used in the inlined lock/unlock function instead of
fetching a new copy. That is why I prefer a more liberal use of
ACCESS_ONCE() for safety purpose.
You can read more on this in Documentation/volatile-considered-harmful.txt
And although I already suggested that, have you read Documentation/memory-barriers.txt? There is a lot of valuable information there.