There are, unfortunately, many kinds of barrier. There's rmb() and
wmb() (combined in mb()), and also at the machine level, there are
barriers to prevent GCC rearranging code, and barriers to prevent the
processor rearranging operations!
If you are right, and I'm not sure if you are, I think you'd want rmb()
when acquiring a lock and wmb() when releasing it.
On x86, a "memory" asm constraint added to the spinlock operations would
be enough -- it is already enough for wmb(), and the rmb() equivalent is
provided by the locking code itself (provided you add "memory" as a
constraint).
Adding general mb() at every spin lock would certainly be overkill.
(See the current x86 implementation of mb() and rmb()).
Requiring spin lock callers to include explicit barriers would also be
overkill, because there is some processor-level barrier effect in the
spin lock code itself -- additional explicit barriers would just add
unnecessarily operations.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/