Messages in this thread | | | Subject | Re: spin_unlock optimization(i386) | Date | Wed, 24 Nov 1999 15:48:00 -0800 | From | Erich Boleyn <> |
| |
> That's not the point. What you should tell me is that I can't reimplement > rmb() without a lock on the bus because the minium common divisor of a > spin_unlock() in pseudocode is not like in the Alpha implementation: > > mb(); > spinlock.lock = 0; > > as I basically stated (I was thinking wrong) in my previous email. > > On Alpha the spin_unlock can't be more finegrined because there's no way > you can _only_ avoid memory accesses before the barrier to be executed > after the barrier and letting accesses after the barrier to be executed > before the barrier. > > I didn't understood well what IA32 enforces in a write: I thought the > write was enforcing order in both directions (up and down).
Presuming normal cacheable memory here...
Processor Ordering is the same as strong ordering except you just may not see all the stores from the other processors yet. There is no violation of program ordering with respect to other processors, and those you do see guarantee you have seen any one earlier in the store sequence. So, in general, I'm not sure what you're trying to accomplish with a read memory barrier on IA32 for cacheable memory.
For the unlock, the use of any store will guarantee that all prior instructions are committed before the results of the store are externally observable.
For the following case:
spin_lock(X); READ Y;
...*regardless* of speculation, the value gotten by "READ Y" will be consistent with anything observed by the processor in "spin_lock", else it violates the program order, and normal programs would not work very well. It's perfectly OK to hoist "READ Y" above "spin_lock" speculatively... for example, consider the following sequence:
-- processor A: "READ Y" is speculatively executed, now waiting to be committed to state. -- processor A: "spin_lock(X)" is spinning in it's loop... -- processor B: executes "STORE Y", then executes "spin_unlock(X)"
Now NOTE:
-- processor A: to observe X for the "spin_lock(X)" to succeed, it *must* observe "STORE Y" first. -- processor A: observing "STORE Y" requires it to throw away the speculative "READ Y" with the possibly wrong value. It may attempt to reexecute "READ Y" at this time with the correct value. -- processor A: now "spin_lock(X)" can see the new value of X and finish.
If there was no dependency on the spinlock variables, then it's irrelevant if "READ Y" was executed before "spin_lock(X)", since you have no idea when the other processor executed "STORE Y". No dependencies are violated.
Erich Boleyn PMD IA32 Architecture Intel
- 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/
| |