我在 64 位 Linux 机器上：
Linux illin793 2.6.32-279.5.2.el6.x86_64 #1 SMP 2012 年 8 月 14 日星期二 11:36:39 EDT x86_64 x86_64 x86_64 GNU/Linux
来自 man futex：
int futex(int *uaddr, int op, int val, const struct timespec *timeout, int *uaddr2, int val3);
因此，这里 futex 使用 32 位值。
Linux 上是否有适用于 64 位值的 futex？
目前在 Linux 上不支持 64 位 futexes。早在 2007 年就有补丁可以添加支持，但我不知道为什么它们没有被集成。
Linux 上没有 64 位 futex 支持，可能是因为 Linus Torvalds 似乎对这个想法死心塌地。引用Ulrich Drepper 提交的 64 位 futex 补丁：
How about you post your code.
Because your questions seem to be total and utter crap.
> - How do you know when there is no more writer waiting? You cannot
> reset a "writer waiting" bit after you wake up one writer without
> waking every single thread waiting for the rwlock and letting them
> fight for it
Sure you can. By looking at the *other*data* that isn't atomic.
So when doing a "write_unlock()" (or whatever you call it - for the kernel
calls it "up_write()") you can look at the non-atomic write counts to
decide whether there are others.
Also note how you can use 64-bit atomic ops to do that all in user space,
without actually requiring 64-bit futex support - as long as the bits that
matter for waking (like "was there more than one pending writer") fit in
the one 32-bit word.
> - - How do you handle the difference between reader-preferred rwlocks
> and writer-preferred rwlocks? In the latter, if a rwlock is locked
> for reading, future readers must be delayed until all writers are
> gone
Again, that's not something that needs to be in the *atomic* part.
It's unquestionable that a rwlock is more than 32 bits, but what I
question is whether you need all those extra bits to be under futex
> - How do you do the accounting for the *timedlock variants? In the
> case of those a functions, if the threads wake due to a timeout,
> you have the decrement the waiter count. But you have only one bit...
Uli, you're not even trying any more.
NO, you don't have just one bit. You have as many bits as you want. It's
just that only 32 of the bits will be relevant for FUTEX_WAIT_OP etc.
值得一读之前和之后的其他消息，因为对使用 32 位 futexes 实现快速读写锁所固有的权衡进行了一些很好的讨论。
Linus 上面的想法是，即使您需要超过 32 个“原子位”来实现您的算法，您也可以通过将附加数据保留在 32 位 futex 值之外来解决 64 位 futex 的不足。后来他详细阐述了该方案的一个变体，建议使用两个相邻的 32 位字，并确保任何给定futex调用需要保护的任何状态都适合 32 位半部分中的一个。您仍然可以在用户空间中同时对两半执行 64 位原子操作，但您只需将自己限制为 32 位子集以进行实际的块/唤醒决策。