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.