[PATCH v2] libgcc, libstdc++: Route steady-clock timedlock through gthread

[Mike Crowe]

On Sunday 22 March 2026 at 17:04:54 +0000, Nick Nikolov wrote:
> On Sunday 22 March 2026 at 15:03:00 +0000, Mike Crowe wrote:
> > Did you consider adding generic __gthread_mutex_clocklock(), etc. functions
> > that take the clock ID as a parameter as direct wrappers of the POSIX
> > functions? I think this would have made the change less invasive and would
> > allow other clocks to be supported in the future too.
> 
> I did consider a generic clock parameter, but clockid_t is a
> POSIX/Linux type  --  it doesn't exist on non-pthreads platforms (which
> is the whole motivation for routing through gthreads). To make it
> portable we'd need to define a gthread-level clock type with its own
> enum values, and then translate those to the platform-specific ones
> in each backend (e.g. gthr-posix.h maps to clockid_t, FreeRTOS maps
> to whatever it uses). Given that we currently only support two clocks
> (system and steady), that abstraction layer felt like unnecessary
> complexity. If more clocks become relevant in the future (CLOCK_TAI,
> CLOCK_BOOTTIME), introducing a __gthread_clockid_t abstraction at that
> point would make more sense  --  and the steady-specific functions could
> be trivially reimplemented in terms of it.

I'm happy with that reason. Let's see if Jonathan agrees.

> > If FreeRTOS also supports read-write locks then equivalent wrapper
> > functions will be required for pthread_rwlock_clockrdlock and
> > pthread_rwlock_clockwrlock.
> 
> FreeRTOS doesn't have native rwlock support, so it wouldn't
> benefit from rwlock wrappers. That said, other gthread backends
> might, so I agree it could be worth adding. Would a follow-up patch
> be acceptable for that, or would you prefer it included here?

If FreeRTOS doesn't require the wrappers then I don't see any reason to add
them yet.

> > IMO _GTHREAD_USE_COND_TIMEDWAIT_STEADY (or equivalent) being defined
> > implies that __gthread_cond_timedwait_steady can be called whereas
> > _GTHREAD_USE_PTHREAD_COND_CLOCKWAIT (or similar) implies that
> > pthread_cond_clockwait() can be called.
> 
> I'd like to avoid _GTHREAD_USE_PTHREAD_* if possible as it leaks the
> implementation through the abstraction  --  the whole point of gthreads
> is that consumers shouldn't need to know whether pthreads is the
> backend.

The consumers of gthread don't need to know. It's just the implementation
of gthr-posix.h that does. Perhaps the defines need to be even more obscure
then: ___GTHREAD__USE_PTHREAD_*? Perhaps there's already precedent for this
somewhere else? (I couldn't find one.)

> The existing precedent is _GTHREAD_USE_MUTEX_TIMEDLOCK: it signals
> that __gthread_mutex_timedlock() is available without mentioning
> pthread_mutex_timedlock in the flag name. gthr-posix.h defines it by
> checking _POSIX_TIMEOUTS, but the flag itself is implementation-
> agnostic  --  a FreeRTOS backend could define it too based on its own
> capabilities.
> 
> _GTHREAD_USE_COND_TIMEDWAIT_STEADY follows the same pattern: it says
> "the gthread layer can do steady-clock condvar waits" without
> prescribing how. gthr-posix.h implements it via pthread_cond_clockwait;
> a FreeRTOS backend would do something different.
>
> > For example, a __gthread_cond_timedwait_steady implementation that called
> > Bionic's pthread_cond_timedwait_relative_np would define
> > _GTHREAD_USE_COND_TIMEDWAIT_STEADY and
> > _GTHREAD_USE_PTHREAD_COND_TIMEDWAIT_RELATIVE_NP but not
> > _GTHREAD_USE_PTHREAD_COND_CLOCKWAIT.
> 
> I'm not opposed to adding a non-gthread flag used only inside
> gthr-posix.h that selects which pthread function to call when
> implementing __gthread_cond_timedwait_steady. But we currently have
> only one implementation. That approach remains available to us in the
> future if we need to select between multiple underlying pthread
> functions.

I think that you are right that this can all be changed in the future if
necessary, so if Jonathan and the libgcc maintainers are happy with it like
this then so am I.

> > I think that it should be up to libgcc to define this when necessary and
> > not libstdc++. It's libgcc that is ultimately responsible for knowing
> > whether it is providing __gthread_cond_timedwait_steady() or not and
> > another language standard library may want to make use of it too.
> 
> I modelled it after _GTHREAD_USE_MUTEX_TIMEDLOCK, which is detected by
> libstdc++'s configure (acinclude.m4), defined in libstdc++'s config.h.in,
> and then consumed by gthr-posix.h. So I followed the same pattern for
> _GTHREAD_USE_COND_TIMEDWAIT_STEADY.
>
> If there's a preferred way to have libgcc own the detection instead,
> I'm happy to restructure it  --  I just wasn't sure how to do that
> given there's no POSIX feature-test macro for pthread_cond_clockwait
> the way _POSIX_TIMEOUTS exists for timedlock.

libgcc has a configure script and a config.in file so I would hope that the
detection can just be moved to them so that gthread is self-contained. Not
that I've tried of course so there might be some reason why this can't work
:-)

IMO _GTHREAD_USE_MUTEX_TIMEDLOCK is being set in the wrong place and should
be moved similarly, but it has been like that for about fifteen years it
would seem!

[snip patch]

Thanks.

Mike.