Changeset View
Standalone View
sys/sys/bitset.h
Show First 20 Lines • Show All 167 Lines • ▼ Show 20 Lines | |||||
} while (0) | } while (0) | ||||
#define BIT_XOR2(_s, d, s1, s2) do { \ | #define BIT_XOR2(_s, d, s1, s2) do { \ | ||||
__size_t __i; \ | __size_t __i; \ | ||||
for (__i = 0; __i < __bitset_words((_s)); __i++) \ | for (__i = 0; __i < __bitset_words((_s)); __i++) \ | ||||
(d)->__bits[__i] = (s1)->__bits[__i] ^ (s2)->__bits[__i];\ | (d)->__bits[__i] = (s1)->__bits[__i] ^ (s2)->__bits[__i];\ | ||||
} while (0) | } while (0) | ||||
/* | |||||
* Note, the atomic(9) API is not consistent between clear/set and | |||||
* testandclear/testandset in whether the value argument is a mask | |||||
* or a bit index. | |||||
*/ | |||||
#define BIT_CLR_ATOMIC(_s, n, p) \ | #define BIT_CLR_ATOMIC(_s, n, p) \ | ||||
atomic_clear_long(&(p)->__bits[__bitset_word(_s, n)], \ | atomic_clear_long(&(p)->__bits[__bitset_word(_s, n)], \ | ||||
__bitset_mask((_s), n)) | __bitset_mask((_s), n)) | ||||
#define BIT_SET_ATOMIC(_s, n, p) \ | #define BIT_SET_ATOMIC(_s, n, p) \ | ||||
atomic_set_long(&(p)->__bits[__bitset_word(_s, n)], \ | atomic_set_long(&(p)->__bits[__bitset_word(_s, n)], \ | ||||
__bitset_mask((_s), n)) | __bitset_mask((_s), n)) | ||||
#define BIT_SET_ATOMIC_ACQ(_s, n, p) \ | #define BIT_SET_ATOMIC_ACQ(_s, n, p) \ | ||||
atomic_set_acq_long(&(p)->__bits[__bitset_word(_s, n)], \ | atomic_set_acq_long(&(p)->__bits[__bitset_word(_s, n)], \ | ||||
__bitset_mask((_s), n)) | __bitset_mask((_s), n)) | ||||
#define BIT_TEST_CLR_ATOMIC(_s, n, p) \ | |||||
(atomic_testandclear_long( \ | |||||
&(p)->__bits[__bitset_word((_s), (n))], (n)) != 0) | |||||
#define BIT_TEST_SET_ATOMIC(_s, n, p) \ | |||||
markj: Is this note worth having in the man page instead? | |||||
Done Inline ActionsMy feeling is no. Which aspect were you thinking? The bitset API is consistent in taking a bit number and not a mask, but the atomic API is not. I feel like the phrasing being added to the man page above is clear about it being the bit number, in the context of the paragraph. Thoughts? The modulus bit was just intended to explain why there's no % _BITSET_BITS in the macro implementation. rlibby: My feeling is no. Which aspect were you thinking?
The bitset API is consistent in taking a… | |||||
Not Done Inline ActionsI see now, before I didn't quite understand what the comment was pointing out. I agree that it doesn't belong in the man page. Honestly, I'm not sure it is very useful: if you understand atomic(9), the note is obvious, and if you don't, then you should read atomic(9). At least, I think it should go before the definition of BIT_CLR_ATOMIC since it applies to the macros above too. markj: I see now, before I didn't quite understand what the comment was pointing out. I agree that it… | |||||
Done Inline ActionsOkay. I can shorten it to a reference to atomic(9) with a warning that the APIs are not the same. rlibby: Okay. I can shorten it to a reference to atomic(9) with a warning that the APIs are not the… | |||||
Not Done Inline ActionsI like that it justifies the difference between use of a mask in the BIT_SET_ATOMIC_ implementation above and use of a bit here. But it’s not a sticking point for me. cem: I like that it justifies the difference between use of a mask in the BIT_SET_ATOMIC_… | |||||
(atomic_testandset_long( \ | |||||
&(p)->__bits[__bitset_word((_s), (n))], (n)) != 0) | |||||
cemUnsubmitted Not Done Inline ActionsHm, should the (n) in the 2nd argument of atomic_testandset_long() be ((n) - __bitset_word((_s), (n)) * 8 * sizeof(long)) or something like that? It seems like the current structure won't work for any bitset_word other than the 0th one. cem: Hm, should the `(n)` in the 2nd argument of `atomic_testandset_long()` be `((n) - __bitset_word… | |||||
cemUnsubmitted Not Done Inline ActionsOr more straightforwardly, ((n) % _BITSET_BITS). cem: Or more straightforwardly, `((n) % _BITSET_BITS)`. | |||||
rlibbyAuthorUnsubmitted Done Inline ActionsI think it works... This is what the last sentence of the original comment was about. rlibby: I think it works... This is what the last sentence of the original comment was about.
The… | |||||
cemUnsubmitted Not Done Inline ActionsOh, I see. Yeah, and the implementation seem to have that behavior as well. It is a surprising API for me. I guess it might be a vote for that comment. cem: Oh, I see. Yeah, and the implementation seem to have that behavior as well. It is a… | |||||
/* Convenience functions catering special cases. */ | /* Convenience functions catering special cases. */ | ||||
#define BIT_AND_ATOMIC(_s, d, s) do { \ | #define BIT_AND_ATOMIC(_s, d, s) do { \ | ||||
__size_t __i; \ | __size_t __i; \ | ||||
for (__i = 0; __i < __bitset_words((_s)); __i++) \ | for (__i = 0; __i < __bitset_words((_s)); __i++) \ | ||||
atomic_clear_long(&(d)->__bits[__i], \ | atomic_clear_long(&(d)->__bits[__i], \ | ||||
~(s)->__bits[__i]); \ | ~(s)->__bits[__i]); \ | ||||
} while (0) | } while (0) | ||||
▲ Show 20 Lines • Show All 69 Lines • Show Last 20 Lines |
Is this note worth having in the man page instead?