[trans-mem] fix futex syscall for x86_64

[Aldy Hernandez]

On Fri, Mar 26, 2010 at 09:39:38AM +0100, Patrick MARLIER wrote:
> Hello,
> 
> Aldy Hernandez wrote:
> >I will look into the remaining deadlock issue(s) next.
> 
> Deadlock problem with rwlock:

Where were you earlier this week when I was pounding my head against a
wall with these deadlocks?!

> In write_lock, futex_wait can return even if futex_wake was not
> called (first phase of futex_wait is to spin on value). So
> this->w_writers is not decremented (only done in case of *_unlock
> with then futex_wake).
> -> w_writers will be increased again by the same thread if it
> doesn't succeed to get the active writer lock.

Exactly.  I just figured this out a few days ago.

> One bad solution could be to test the return of futex_wait if it
> returns due to wake or not for decrementing w_writers. But in this
> case, we have a race between futex_wait returns and the acquisition
> of summary lock.

Unfortunately I tried this.

> example:
> 1. one thread enter futex_wait but the value changed then returns
> immediately.
> 2. in between, a read_unlock finishes and get the summary lock,
> decrements w_writers and futex_wake on it.
> 3. finally the writer thread will acquire the summary lock and
> decrements w_writers.

...and ran into this :).

> One solution is to let the waiting writer thread to decrement the
> w_writers value but then we cannot use w_writers for futex_wait.
> (this->summary could be used but will do too many useless wake up)

Richard has suggested removing the futex implementation altogether,
since there's not as much to be gained because of the busy loop on the
summary lock.

The POSIX mutex implementation does not suffer from these anomalies,
because pthread_cond_wait() will do the wait and lock in one atomic
operation, unlike our broken futexes.

So worry not, this whole futex business is getting ripped out soon.

Thanks so much for analyzing this.  Your help is greatly appreciated.
Aldy