On Friday 19 October 2007 19:14, Zoltan Menyhart wrote: > You may want to avoid assembly magics: > > static __inline__ void > __clear_bit_unlock(int const nr, volatile void * const addr) > { > volatile __u32 * const m = (volatile __u32 *) addr + (nr >> 5); > > *m &= ~(1 << (nr & 0x1f)); > } > > GCC compiles volatile loads with ".acq" and stores with ".rel". Hmm, more arbitrary volatile semantics :( Actually I personally would prefer to use a non-volatile pointer, and do the assembly explicitly. However, that's not for me to decide. Importantly, the load with acquire is not required and I agree it should go. Thanks for noticing that. > Another remark: > We are adding more variants of existing funtions, e.g.: > > clear_bit() > __clear_bit() > > I've got problems with hidden semantics. Double underscore prepended versions of the bitops are always non-atomic. This is nothing new. Functions with "lock" or "unlock" in their names are relatively clear to be acquire and release. I preferred to stay with the lock / unlock theme rather than introduce the new acquire and release barriers into the kernel. Of course they are the same thing really, but lock/unlock is always associated with locking and unlocking something. I don't want people to use the acquire/release semantics of these things for anything except taking and releasing a lock (in which case you really don't have to worry much about memory ordering issues). > Just reading the source (where they are used), I simply cannot guess > if a primitive is atomic or not, if it is with some fencing or w/o. > > Cannot we have some "speaking names"? E.g.: bit_unlock_Natomic_rel() I used the double underscore prefix for bit_unlock simply because it is pretty well associated with the bitops code. I personally do not like _Natomic postfix though. Also _rel definitely is redundant because an unlock operation is not exactly an unlock operation if it doesn't provide the right memory ordering. - To unsubscribe from this list: 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
![]() |