Chen, Kenneth W wrote:
Nick Piggin wrote on Tuesday, March 28, 2006 6:36 PM
Hmm, not sure. Maybe a few new bitops with _lock / _unlock postfixes?
For page lock and buffer lock we'd just need test_and_set_bit_lock,
clear_bit_unlock, smp_mb__after_clear_bit_unlock.
I don't know, _for_lock might be a better name. But it's getting long.
I think kernel needs all 4 variants:
clear_bit
clear_bit_lock
clear_bit_unlock
clear_bit_fence
And the variant need to permutated on all other bit ops ... I think it
would be indeed a better API and be more explicit about the ordering.
We could just introduce them as required, though? clear_bit_fence shouldn't
be required for ia64 any longer, if you change bitops to be full barriers,
right?
And for now, let's just not let people open critical sections unless doing
a test_and_set, nor close them unless doing a plain clear?
It seems that memory ordering model seems to be almost too much for people
to cope with already, so would it be reasonable to require some performance
justification before adding more?
--
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
