lkml.org 
[lkml]   [1999]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] new spinlock variant, spinlock-2.3.30-A4
Date
From: Andrea Arcangeli <andrea@suse.de>
> On Tue, 30 Nov 1999, Ingo Molnar wrote:
>
> >no, spin_lock() must guarantee that instructions within the critical
> >section only execute at one CPU at once. Ie. all effects of the critical
>
> Without the lock on the bus reads could happen before the spin_lock().
> Thus instructions into the critical section would execute on two CPUs at
> the same time.
>
Could you try to trigger this problem?

eg cpu1 owns the spinlock:
write DATA
spin_unlock, ie write LOCK_1

cpu2 acquires the lock:
"asm: read LOCK_1; read DATA", the cpu could reorder the read operation.

if cpu2 gets the lock, then it has seen the "write LOCK_1" from cpu1.
but this automagically means that it has also seen the "write DATA" from
cpu1.

It seems that the cpu discards speculative reads if it sees a write
operation on
the system bus (I tried to force a speculative read, and my proggy never
failed)

--
BUT: I don't know if we should rely on this: 15 ticks vs 22 ticks is not a
very large
difference, and I don't know if this behaviour is guaranteed.

Ingo, do your new spin_lock() functions clobber any registers? This would
further
increase the costs in "real life".

Cheers,
Manfred


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