Messages in this thread | | | Date | Tue, 30 Nov 1999 20:06:14 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: [patch] new spinlock variant, spinlock-2.3.30-A4 |
| |
On Tue, 30 Nov 1999, Manfred Spraul wrote:
> spin_lock() must be a full memory barrier, we could relax the rules for > spin_unlock _only_ because read reordering of the x86 is asymetric.
no, spin_lock() must guarantee that instructions within the critical section only execute at one CPU at once. Ie. all effects of the critical section are either fully visible to another critical section, or not visible at all - this is guaranteed by Processor Ordering and the spinlock variant. _How_ this all happens, what is executed and where and in what order is completely irrelevant.
yes, it's more vulnerable to processor/chipset bugs. (I'd still like to see your testcase folded into C and causal.c so that we can make more formal validation.)
-- mingo
- 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/
| |