Currently the futex system call is not exposed by glibc.  This makes it mildly
painful to make direct futex calls.  Calling the futex system call directly is
useful when implementing low level synchronization code which does not easily
fit the mutex/condition variable pattern or the semaphore pattern.

Please consider adding the futex function call to future glibc versions.

int futex(int *uaddr, int op, int val, const struct timespec *timeout,
          int *uaddr2, int val3);

We have the syscall function.

Can we please revisit the question of exposing a public futex function and assocated macros? Using syscall.h from applications is a horrible hack. Now that C11 has atomics, the demand for working directly with atomics is likely to increase, but for lots of applications of atomics you also need futex().

If this is acceptable, my preferred header for the interface would be sys/futex.h.

Also, the function should probably be variadic with the required arguments dependent on "op", rather than having fixed argument types.

I don't consider Bugzilla a good place for suggesting possibly 
controversial new features.  If someone is interested in this, they should 
update / expand the analysis from previous discussions (see 
<https://sourceware.org/ml/libc-alpha/2013-02/msg00030.html>, for example) 
of syscalls without corresponding glibc functions, giving a detailed 
analysis / links to the arguments from both the Jan/Feb 2013 discussion 
and that in May/Jun 2012, post to libc-alpha and help lead the discussion 
to consensus, and then send a patch or patches to implement the consensus.  
In the absence of someone committed to seeking then implementing consensus 
in the near term, the bug should be closed as INVALID (inappropriate forum 
for something that's not a clear defect).

On Mon, Feb 10, 2014 at 03:18:31PM +0000, joseph at codesourcery dot com wrote:
> I don't consider Bugzilla a good place for suggesting possibly 
> controversial new features.

That's odd, because last time I was asked to open a bugzilla entry for
such an issue (lack of async-signal-safety of dprintf I believe). I
thought wishlist/feature-request items were supposed to be on the
tracker.

On Mon, 10 Feb 2014, bugdal at aerifal dot cx wrote:

> http://sourceware.org/bugzilla/show_bug.cgi?id=9712
> 
> --- Comment #5 from Rich Felker <bugdal at aerifal dot cx> ---
> On Mon, Feb 10, 2014 at 03:18:31PM +0000, joseph at codesourcery dot com wrote:
> > I don't consider Bugzilla a good place for suggesting possibly 
> > controversial new features.
> 
> That's odd, because last time I was asked to open a bugzilla entry for
> such an issue (lack of async-signal-safety of dprintf I believe). I
> thought wishlist/feature-request items were supposed to be on the
> tracker.

Only where they are self-contained and there is clear consensus about the 
desirability of the feature as well as a clear way of telling whether the 
issue has been resolved; not where a more complicated analysis, discussion 
and consensus-building process is needed, as here.  More open-ended 
project ideas, if you're not going to push the process through from 
analysis to implementation, and where there may not be consensus, go on 
the todo list on the wiki.  In this case, we need to agree on general 
principles for when syscalls should be directly exposed, then apply those 
principles to determine a list to expose, which might or might not include 
futex.

*** Bug 17168 has been marked as a duplicate of this bug. ***

Based on the request which I just marked as a duplicate of this one, I think this is a new argument for adding a public futex function: the desire to have it be a cancellation point, which cannot be achieved by calling it directly with syscall(). See my comment 20 on issue #12683 for details.