Re: __ASSUME_PRIVATE_FUTEX and __ASSUME_FUTEX_CLOCK_REALTIME

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2015-06-09 at 16:20 -0700, Roland McGrath wrote:
> > On Fri, 2014-06-20 at 16:15 -0700, Roland McGrath wrote: 
> > > > __ASSUME_PRIVATE_FUTEX and __ASSUME_FUTEX_CLOCK_REALTIME are defined for 
> > > > all supported Linux kernel versions.  Should we say they are a required 
> > > > part of the futex interface for any system, whether or not using the Linux 
> > > > kernel, that may wish to use NPTL, and so remove these macros and all 
> > > > conditionals testing them everywhere in glibc, not just in 
> > > > sysdeps/unix/sysv/linux/ files?
> > > 
> > > Please, no.  Other systems that provide a futex layer may well provide a
> > > much less fully featureful one than Linux has.
> > 
> > Roland, do you see any reason why having __ASSUME_FUTEX_CLOCK_REALTIME
> > or not couldn't be contained in the internal futex abstraction layer?
> > That is, we could have a futex_timed_wait that just does the right thing
> > on Linux, and does something different but conforming on non-Linux?
> > This might be similar for __ASSUME_PRIVATE_FUTEX, but I haven't looked
> > at this closely.
> 
> I certainly think that these variations should be folded into the new
> internal futex interface in some fashion.  There is nothing to love about
> the existing #if nests.  At the time of this discussion, I was displaying a
> bit of generic paranoia about changing things in ways that might make life
> more difficult for me in the NaCl port.  Now we have the context of the
> NaCl port in the tree so all my concerns will be addressed by taking care
> to make sure new internal interfaces make things better for the NaCl port,
> which can now be seen concretely.  NaCl's futex support is about as minimal
> as futex support could be, but may well be augmented in the future; so
> something that is a good fit for today's Linux as well as NaCl should cover
> the theoretical spectrum well.

I think it is possible to remove it.  We always assume private futex and
futex support for realtime clocks on Linux, so from a Linux perspective,
we don't need any of this.

>From a non-Linux perspective, I think the question is (1) whether you
want to have hooks at your disposal that initialize flags on program
startup, and (2) whether we want to make the decision of private/shared
at datastructure initialization time vs. at futex call time.

It seems you don't need (1) right now because you ignore private/shared
and you know a priori whether NaCl supports absolute timeouts.
(2) is also not really relevant I believe because none of the futex
calls are on real fast paths, so getting a flag from some location at
every futex call seems fine.  (futex_wait* is always the slow path; we
optimize in concurrent data structures such as semaphores to avoid
futex_wake if possible.)

> In fact, I'd like the new internal interface to cover the issue of varying
> feature support so as to be a user-visible improvement for the NaCl case.
> That is, make sure that functions like pthread_condattr_setclock and
> pthread_mutexattr_setpshared diagnose the unsupported features up front.

Would shared or private be unsupported in practice, ever?  If shared is
unsupported, this only matters if one can indeed map glibc data
structures between processes -- so only if that other functionality does
not return an error.  If private is unsupported, shared is fine as well.
Would you still like to see the futex API offering an is_supported()
function or such?

Regarding the clocks, only condvars use it currently AFAIK.  I'll have
to have a closer look at what the existing condvar impl really did and
whether I've handled it correctly in the new condvar impl.  If there is
anything to change in the futex API, I'll introduce that with the patch
that moves the new condvar over to the new API.

Sounds good?