问题
I am on a 64-bit Linux box:
Linux illin793 2.6.32-279.5.2.el6.x86_64 #1 SMP Tue Aug 14 11:36:39 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
From man futex:
int futex(int *uaddr, int op, int val, const struct timespec *timeout, int *uaddr2, int val3);
So, here futex works with 32-bits value.
Is there futex on Linux that works with 64-bits value?
回答1:
There is currently no support for 64-bit futexes on Linux. There have been patches to add support circulating from as far back as 2007, but I have no idea why they haven't been integrated.
回答2:
There is no 64-bit futex support on Linux, probably because Linus Torvalds seems to be dead-set against the idea. Quoting from a 64-bit futex patch submitted by Ulrich Drepper:
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.
It's worth reading the other messages before and after this one, because there is some good discussion of the tradeoffs inherent in implementing a fast read-write lock with 32-bit futexes.
Linus's idea above is that even if you need more than 32 "atomic bits" to implement your algorithm, you can probably work around the lack of 64-bit futexes by keeping your additional data outside of the 32-bit futex value. Later on he elaborates on a variant of that scheme, suggesting using two adjacent 32-bit words and ensuring that whatever state needs to be protected by any given futex call fits into one of the 32-bit halves. You can still do 64-bit atomic operations on both halves simultaneously in user space, but you just have to restrict yourself to a 32-bit subset for the actual block/wake decisions.
来源：https://stackoverflow.com/questions/14827885/linux-futex-for-64-bits