RE: Synchronizing Bit operations V2
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: davem@xxxxxxxxxxxxx
- Subject: RE: Synchronizing Bit operations V2
- From: Christoph Lameter <clameter@xxxxxxx>
- Date: Fri, 31 Mar 2006 13:28:13 -0800 (PST)
- Cc: "Chen, Kenneth W" <kenneth.w.chen@xxxxxxxxx>, "'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: <200603312123.k2VLNqg06655@xxxxxxxxxxxxxxxxxxxx>
- References: <200603312123.k2VLNqg06655@xxxxxxxxxxxxxxxxxxxx>
On Fri, 31 Mar 2006, Chen, Kenneth W wrote:
> > I think we could say that lock semantics are different from barriers. They
> > are more like acquire and release on IA64. The problem with smb_mb_*** is
> > that the coder *explicitly* requested a barrier operation and we do not
> > give it to him.
>
> I was browsing sparc64 code and it defines:
>
> include/asm-sparc64/bitops.h:
> #define smp_mb__after_clear_bit() membar_storeload_storestore()
>
> With my very naïve knowledge of sparc64, it doesn't look like a full barrier.
> Maybe sparc64 is broken too ...
Dave, how does sparc64 handle this situation?
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]