Christoph Lameter wrote:
Hmmm... Maybe we therefore need to add a mode to each bit operation in the kernel?With that we can also get rid of the __* version of bitops. Possible modes are NON_ATOMIC Do not perform any atomic ops at all. ATOMIC Atomic but unordered ACQUIRE Atomic with acquire semantics (or lock semantics) RELEASE Atomic with release semantics (or unlock semantics) FENCE Atomic with full fence. This would require another bitops overhaul.Maybe we can preserve the existing code with bitops like __* mapped to *(..., NON_ATOMIC) and * mapped to *(..., FENCE) and the gradually fix the rest of the kernel.
Form semantical point of view, the forms: bit_foo(..., mode) and bit_foo_mode(...) are equivalent. However, I do not think your implementation would be efficient due to selecting the ordering mode at run time:
+ switch (mode) { + case MODE_NONE : + case MODE_ACQUIRE : + return cmpxchg_acq(m, old, new); + case MODE_FENCE : + smp_mb(); + /* Fall through */ + case MODE_RELEASE : + return cmpxchg_rel(m, old, new);
+ if (mode == ORDER_NON_ATOMIC) { + *m |= bit; + return; + }
etc. In addition, we may want to inline these primitives... A compile-time selection of the appropriate code sequence would help. Thanks, Zoltan - : 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
![]() |