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

Manfred Spraul <manfreds@colorfullife.com> wrote:

> [Either my test program is completely buggy, or ]
>
> We definitively need the memory barrier during set_current_state():
>
> I've attached a samle program that mimics __wait_inode(), and it always
> locks up with the normal "mov" and the correct delay between the wake-up
> and the sleep functions.

Ah, OK. An interesting case.

I believe this program demonstrates I was being too simplistic in
my definition of "Processor Ordering". I'll take my lumps here and we'll
move on.

The answer isn't that reads are speculating earlier in time willy-nilly.

The answer is the somewhat more subtle one that all processors MUST agree
on the resulting value for the location in question (since we're doing
coherent memory). The stores are delayed, so when an "external observation"
from processor B appears on processor A, and processor A has a conflicting
store in it's queue of committed stores, who wins?

Answer: The last processor to "externally observe" it's store.
(actually, this isn't quite true, you just need to assure that one
of them will win). I.e. processor A is insisting on the value being
what it has in it's queue of committed but not yet "externally
observed" stores.

So, I guess we do get a kind of causality violation here.

In the example program, the problem was when the first processor's store
to "current_state" stomps the one done by the second processor, even
though that store is LATER in observed order on the first processor.

The LOCKed case working was because it drained the first processor's
store queue, therefore not leaving anything around to conflict with the
observed stores from other processors after the critical read.


--
Erich Boleyn
<esboleyn@ichips.intel.com>
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.115 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site