On Wed, Apr 03 2019, David Laight wrote: > From: NeilBrown >> Sent: 02 April 2019 22:11 >> >> On Tue, Apr 02 2019, David Laight wrote: >> >> > From: NeilBrown >> >> Sent: 02 April 2019 00:08 >> >> >> >> This patch changes rhashtables to use a bit_spin_lock on BIT(1) of the >> >> bucket pointer to lock the hash chain for that bucket. >> > ... >> >> To enhance type checking, a new struct is introduced to represent the >> >> pointer plus lock-bit >> >> that is stored in the bucket-table. This is "struct rhash_lock_head" >> >> and is empty. A pointer to this needs to be cast to either an >> >> unsigned lock, or a "struct rhash_head *" to be useful. >> >> Variables of this type are most often called "bkt". >> > >> > Did you try using a union of the pointer and an 'unsigned long' ? >> > Should remove a lot of the casts. >> >> It might, but I'm not sure it is what we want. >> The value is not an unsigned long OR a pointer, it is both blended >> together. So it really isn't a union. >> We *want* it to require casts to access, so that it is clear that >> something unusual is happening, and care is needed. > > Right, but you also want to make it hard to forget to do it properly. > Using a union to access the memory as either a pointer or a long > is perfectly valid (and is valid with 'strict aliasing' enabled). > (Rather than the other use of a union to just save space.)
Agreed.... I personally think that a union make it easy to forget. > > An interesting thought.... > Are the only valid actions 'lock and read, and 'unlock with optional update' ? No, there is also "read without locking" - use for lookups with RCU protection. But yes: the set of valid actions is quite limited. > If so there are only 2 bits of code that need to understand the encoding. > If you make the bit number(s) and polarity properties of the architecture > you should be able to make the stored value an invalid pointer (locked > and unlocked) on at least some architectures. I'd rather avoid writing arch-specific code if I can avoid it. It isn't clear that the value of your proposal justifies the cost. Over-loading the low-order bits of a pointer is (I think) a well understood pattern. I'd rather stick with such patterns. Thanks, NeilBrown > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales)
signature.asc
Description: PGP signature
