lkml.org 
[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.089 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site