RE: Synchronizing Bit operations V2
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "'Christoph Lameter'" <clameter@xxxxxxx>
- Subject: RE: Synchronizing Bit operations V2
- From: "Chen, Kenneth W" <kenneth.w.chen@xxxxxxxxx>
- Date: Thu, 30 Mar 2006 19:17:49 -0800
- Cc: "Nick Piggin" <nickpiggin@xxxxxxxxxxxx>, "Zoltan Menyhart" <Zoltan.Menyhart@xxxxxxxx>, "Boehm, Hans" <hans.boehm@xxxxxx>, "Grundler, Grant G" <grant.grundler@xxxxxx>, <akpm@xxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <linux-ia64@xxxxxxxxxxxxxxx>
- In-reply-to: <Pine.LNX.4.64.0603301909590.3145@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Thread-index: AcZUcOq3zmzy2yEaTL6XZJMfzv7kWwAAHd/w
Christoph Lameter wrote on Thursday, March 30, 2006 7:12 PM
> > On ia64, we map the following:
> > #define Smp_mb__before_clear_bit do { } while (0)
> > #define clear_bit clear_bit_mode(..., RELEASE)
> >
> > Which looked perfect fine to me. I don't understand why you say it does
> > not provide memory ordering.
>
> It does not provide a memory barrier / fence. Later memory references can
> still be moved by the processor above the instruction with release semantics.
That is perfect legitimate, and was precisely the reason for the invention of
smp_mb__after_clear_bit - prevent later load to leak before clear_bit.
-
: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]