Christoph Lameter wrote on Thursday, March 30, 2006 7:12 PM > > > We are talking about IA64 and IA64 only generates an single instruction > > > with either release or acquire semantics for the case in which either > > > smb_mb__before/after_clear_bit does nothing. > > > > > > Neither acquire nor release is a memory barrier on IA64. > > > > > > The use of > > smp_mb__before_clear_bit(); > > clear_bit( ... ); > > > > is: all memory operations before this call will be visible before > > the clear_bit(). To me, that's release semantics. > > What of it? Release semantics are not a full fence or memory barrier. > > > 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. This is probably a classic example of a sucky name leads to confusion. There are smp_mb_ in the name, however, the semantics is really defined as a one-way memory barrier and probably is the main reason of contention in this discussion :-( Another good reason to get rid of this silly smp_mb_before/after_clear_bit. - Ken wrong confusing implementation - : 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
![]() |