Inefficient implementation of futex

[nyh]

As comments in linux.cc explain, our current futex implementation was not optimized for performance, because the only real use we saw for it was in gcc's _cxa__guard* functions, which are very rarely contended - and only when contended call the futex functions. So we just cared about the correctness of the futex implementation, not its performance.

However, it turns out that golang does use futexes heavily - @benoit-canet noted 10,000 per second (across a few cores) in one run. At that point, having such a bad implementation is not a good idea. Some of the bad things about the current implementation:

1. All the futexes, even unrelated ones, contend on one lock for the list of futexes.
2. If a futex is reused often, we constantly create wait queue objects and then delete them.
3. And probably other things :-)

In #23 there was one idea on how we can have a lock-free futex implementation. But it is likely that with some thought, even a locking implementation could be better.

[nyh]

Some untested quick hacks we can use to determine which inefficiencies might be causing performance problems in an actual use case:

1. We can trivially replace the single queues_mutex and queues by an array of (say) 100 of those (mutexes and maps), and pick the uaddr%100'th mutex and map. This should take contention of this lock out of the equation.

2. The constant allocation and deallocation of the wait queue objects may be slow. We can comment out the queues.erase(i) line in the code to take it out of the equation.

[nyh]

Another untested idea:
The 100 maps in the above idea could be protected by spinlocks (yikes!) instead of mutexes because we know they will only be held for very short durations (and our spinlock does not yet have short-wait spinning optimization).
Then, each "waitqueue" in the map could be, instead, a lock-free queue of waiters, <lockfree/queue-mpsc.hh>.