Messages in this thread | | | Date | Thu, 25 Nov 1999 16:11:19 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: spin_unlock optimization(i386) |
| |
On Fri, 26 Nov 1999, Ingo Molnar wrote: > > i believe the lack of symmetry is due to the unique assymetry of 'lock > aquire' operations vs. 'lock release'. lock-acquire has to be an atomic > test-and-set, and this can only be guaranteed via explicit MESI-helped > LOCK-prefix instructions. The 'lock release' operation on the other hand > can be executed without caring too much about the current state of the > lock, because we _know_ that we are holding the lock already. This unique > assymetry is true even in the Strongly Ordered memory model with no > speculative reads done at all.
I disagree.
Without any speculative reads, you don't need serialization. It would be enough that "lock" just guaranteed that the operation was done atomically.
But I bet that it's more than the atomicity. The serialization is actually needed to make sure that no reads speculate "upwards" to before the locked intruction.
And the reason we don't need serialization on the unlock side (where atomicity is simpleto guarantee, because it's a single operation) is because Intel doesn't ever move reads "downwards" past a write, so the single write basically does act as a complete ordering downwards.
And THAT is the assymetry: intel can and will re-order
write A read B
but intel will probably NOT ever re-order
read A write B
(And everybody agrees that intel will never re-order two writes in any way that can be detected)
If Intel only needed to be atomic, doing the "lock btsl" would not need to take 22 cycles. The cost comes from being a syncronization barrier, which is needed to avoid the re-ordering that intel _will_ do.
But note that a single write will NOT act as a "complete memory barrier" as implied by the Linux "mb()" macro. The single write will make sure that a read does now move downwards _outside_ the lock (which is all that a spinlock cares about) - the single nonsynchronizing write does not guarantee that reads won't move upwards _into_ the critical region.
(moving reads _into_ the critical region is fine - it makes the critical region "bigger", but as the reason for moving the reads up is to allow more parallellism, it doesn't actually make the critical region any slower, which is all that we care about - and it does speed up the exit from the protected region).
Linus
- 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/
| |