Messages in this thread | | | From | "Chen, Kenneth W" <> | Subject | RE: Synchronizing Bit operations V2 | Date | Thu, 30 Mar 2006 18:51:25 -0800 |
| |
Chen, Kenneth W wrote on Thursday, March 30, 2006 6:45 PM > Christoph Lameter wrote on Thursday, March 30, 2006 6:38 PM > > > > Neither one is correct because there will always be one combination of > > > > clear_bit with these macros that does not generate the required memory > > > > barrier. > > > > > > Can you give an example? Which combination? > > > > For Option(1) > > > > smp_mb__before_clear_bit() > > clear_bit(...)( > > Sorry, you totally lost me. It could me I'm extremely slow today. For > option (1), on ia64, clear_bit has release semantic already. The comb > of __before_clear_bit + clear_bit provides the required ordering. Did > I miss something? By the way, we are talking about detail implementation > on one specific architecture. Not some generic concept that clear_bit > has no ordering stuff in there.
By the way, this is the same thing on x86: look at include/asm-i386/bitops.h:
#define smp_mb__before_clear_bit() barrier() #define smp_mb__after_clear_bit() barrier()
A simple compiler barrier, nothing but #define barrier() __asm__ __volatile__("": : :"memory")
See, no memory ordering there, because clear_bit already has a LOCK prefix.
- Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |