lkml.org 
[lkml]   [1999]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: spin_unlock optimization(i386)
Date
From

> 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/

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