lkml.org 
[lkml]   [1999]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: spin_unlock optimization(i386)
Jeff V. Merkey wrote:
> I did see some cases
> where the piplines had already pre-fetched (I assume during address
> generation interlock) data that subsequently got changed and the '0'
> opertion got missed by other processors. This was not a problem in the
> real world, because those processors waiting on the lock simply had to
> wait an extra couple of clocks before they saw the lock get set to '0',
> but what Linus is saying is correct -- there is an infintesimally small
> window where this can occur, and I've seen it on your PPro hardware.

Jeff, you don't seem to be describing the same problem as Linus and Erich.

Linus says that a read instruction before the spin-unlock write
instruction may defer the read until after after the write, because
although writes are guaranteed to execute in order, reads are not.
(According to the processor manuals). Therefore the read, which should
be protected inside the spinlock context, actually reads from outside
the spinlock context.

You on the other hand are saying that the spin-unlock write may not be
seen immediately by other processors. That's ok. It adds an occasional
delay, but doesn't break the assumption that operations in the spinlock
context are all seen (reads and writes) by other processors when the
spinlock is seen to be locked.

It seems to me your observation is consistent with what Erich has to
say, and that Erich is saying the spin-unlock optimisation is safe.
Though it's not obvious from the processor manual.

-- Jamie

-
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.033 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site