Messages in this thread | | | Date | Sun, 10 Jan 1999 00:40:35 +0000 | From | Jamie Lokier <> | Subject | Re: tutorial question: where mb() is needed? |
| |
On Thu, Jan 07, 1999 at 09:29:11PM +0100, Andrea Arcangeli wrote: > On Wed, 6 Jan 1999, Ryan Moore wrote: > > Presumably all of this code isn't in a locked section for performance > > reasons. Instead, the scheduler is relying on the fact that the scheduler > > on another processor won't mess with this current process unless the > > has_cpu is zero. > > Understood. But so what about spinlocks? Should we run a mb() a bit before > releasing every spinlock? When we release the spinlock obviously we need > that all write/read operation in the critical section are just finished > and flushed in order to avoid SMP races, right?
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/
| |