Re: Poor condvar performance

Alexander Terekhov wrote:
> > Using the futex API directly?
> 
> Current futex API isn't really good, so to speak. Redesign is 
> needed for better locks and condvars (with real wait-morphing 
> for both signal and broadcast). See "Linux futex" thread on 
> comp.programming.threads. 

Thanks Alex.  I don't have easy access to usenet, but have just read
the thread using Google news.  It is quite an amusing thread, as :)

You say many times that the futex API is broken, but you tend to be
quite vague about what is actually broken.

Your point about wait-morphing and the wait bit is valid.  It would
save a futex_wake system call in condvar broadcasts, _but_ it would
remove the generality of futexes - currently the kernel knows nothing
about the bit pattern in each futex word.  This is important.

Your point about "real time" is quite unclear.  I did not see any good
explanation of what problam you are talking about.  (You could mean a
lot of things).

Real-time futexes have been raised on linux-kernel long ago as I'm
sure you know, but the proposal and patch then implied a particular
choice of real-time futex wakeup policy that contradicts the FIFO
wakeup principle which some code assumes.  There is room for
improvement, and that could easily be added _if_ a convincing argument
for it is made.

You point about pshared convar broadcasts to pshared mutexes at
different addresses in different processes is real enough.

A couple of NPTL bugs you pointed out seem real based on a brief
reading of your articles, but they are nothing to do with futex;
rather, they are (or perhaps were) NPTL bugs which can be fixed in
userspace.

Finally, regarding your point about 32-bit futexes on 64-bit platforms
not being useful for waiting on pointer changes.  I thought that at
first too, but then I realised: (a) this is true for NULL/non-NULL
pointer changes e.g. when waiting on a list, but often you need
another bit to tell a pointer changer to call futex_wake when it
changes a pointer value between two non-NULL values, so a separate
locking word is used then anyway.  (b) if futexes were 64-bit on
64-bit platforms, they could not be used as record locks inside files
such as database files which need to be binary compatible across
platforms.  So it would be necessary to extend the API to have _both_
32-bit and 64-bit tests, at which point it's getting slower and
bulkier, _and_ you can't reliably offer a 64-bit test on a 32-bit
platform.

-- Jamie