Linux futex为64位

时间:2013-02-12 07:55:04

标签: linux futex

我在64位Linux机器上:

  

Linux illin793 2.6.32-279.5.2.el6.x86_64#1 SMP Tue Tue Aug 14 11:36:39   EDT 2012 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上的futex是否可以使用64位值?

2 个答案:

答案 0 :(得分:2)

Linux上目前不支持64位futex。早在2007年就有补丁来增加支持,但我不知道它们为什么没有被整合。

答案 1 :(得分:0)

Linux上不支持64位futex,这可能是因为Linus Torvalds似乎对此想法持反对态度。引自Ulrich Drepper提交的a 64-bit futex patch

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位子集即可进行实际的块/唤醒决定。