I've tried the futex (with the PRIVATE wait and wake) operators and didn't see appreciable difference between that approach and the existing mutex-condvar form. If we're really going to block or unblock threads, the extra overheads from the mutex-condvar layer are a tiny fraction of the overall path.
The mutex should suffer contention infrequently, so the main cost of the mutex-condvar form is arguably the atomics -- a local cost -- associated with the mutex.
When I've floated the idea direct futex usage, folks have expressed concern about the portability & stability of the interface over the wide range of supported linux distributions. This strikes me as a reasonable concern. (We prefer "PRIVATE" for instance, but do all targeted distributions support that flavor?).
p.s., it might make sense to check that the virtual address placement of condvar -- which is fairly regular -- doesn't interact poorly with the futex hash chain function, possibly resulting in excessive collisions and poor distribution over the chains. This issue would apply to both direct futex usage and the condvar-mutex forms.
On 25/08/17 20:12, David Dice wrote:
> When I've floated the idea direct futex usage, folks have expressed concern
> about the portability & stability of the interface over the wide range of
> supported linux distributions.
I suspect that concern is unjustified. The interface between the
kernel and libc is, if anything, more stable than that between libc
and users' code. There is no possibility of anyone breaking the
futex interface, but it all depends on how far back you want to go.
> This strikes me as a reasonable concern.
> (We prefer "PRIVATE" for instance, but do all targeted distributions
> support that flavor?).
Mmm, okay, you're worried about ancient kernels. Seems unlikely,
but I take your point.