On Tue, 28 Jul 2015, Darren Hart wrote:

Found it on libc-alpha, here it is for reference:

	From: Rich Felker [off-list ref]
	Date: Wed, 29 Oct 2014 22:43:17 -0400
	To: Darren Hart [off-list ref]
	Cc: Carlos O'Donell [off-list ref], Roland McGrath [off-list ref],
	Torvald Riegel [off-list ref], GLIBC Devel [off-list ref],
	Michael Kerrisk [off-list ref]
	Subject: Re: Add futex wrapper to glibc?

	On Wed, Oct 29, 2014 at 06:59:15PM -0700, Darren Hart wrote:
	> > We are IMO at the stage where futex is stable, few things are
	> > changing, and with documentation in place, I would consider adding a
	> > futex wrapper.
	> 
	> Yes, at least for the defined OP codes. New OPs may be added of
	> course, but that isn't a concern for supporting what exists today, and
	> doesn't break compatibility.
	> 
	> I wonder though... can we not wrap FUTEX_REQUEUE? It's fundamentally
	> broken.  FUTEX_CMP_REQUEUE should *always* be used instead. The glibc
	> wrapper is one way to encourage developers to do the right thing
	> (don't expose the bad op in the header).

	You're mistaken here. There are plenty of valid ways to use
	FUTEX_REQUEUE - for example if the calling thread is requeuing the
	target(s) to a lock that the calling thread owns. Just because it
	doesn't meet the needs of the way glibc was using it internally
	doesn't mean it's useless for other applications.

	In any case, I don't think there's a proposal to intercept/modify the
	commands to futex, just to pass them through (and possibly do a
	cancellable syscall for some of them).

Fair enough. Did not think about the requeue to futex held by the
caller case. In that case FUTEX_REQUEUE works as advertised.

Thanks,

	tglx