64位的Linux futex

Question

我在一个64位的Linux机器上：

Linux illin793 2.6.32-279.5.2.el6.x86_64 #1 SMP Tue Aug 14 11:36:39 x86_64 GNU/Linux

来自：

int futex(int *uaddr，int op，int val，const struct timespec *timeout，int *uaddr 2，int val3)；

因此，这里futex的工作值为32位。

Linux上有64位值的futex吗？

Answer 1

目前Linux上不支持64位futexes。早在2007年就有补丁可以添加支持，但我不知道为什么它们还没有集成。

Answer 2

Linux上没有64位的futex支持，可能是因为似乎坚决反对这个想法。引用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位的子集上，用于实际的块/唤醒决策。