I call bull on that.
We've had a 32-bit rwsemaphore in the kernel for a *long* time.
I think it's totally stupid for glibc to even *try* to do something like
this, since almost nobody will have a kernel with 64-bit futex support for
a long time in the wild anyway. So you need to support a 32-bit semaphore
in practice, and it's been done before.
The x86 kernel rwsem implementation may limit things to 64k readers (I'm
not even sure that's true, I'm not going to look at the code again), but
if I recall correctly that's just because we wanted to use a single "xadd"
in the hotpath, instead of doign a load a cmpxchg.
I really object to adding another 32/64-bit difference just for something
like an rwsemaphore. It needs a whole lot of stronger reasons than that.
I suspect the old rwlocks are simply just stupid. You can do those things
with a single 32-bit locked op. Have you tried
- 29 bits of reader counts
- 1 bit of uncontended writer
- 1 bit of "contention" (ie a mark for requiring fairness)
- 1 bit for a spinlock so that you can do all the fairness without doing
any extra locked ops
or similar?
Linus
--
