Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[Rich Felker <dalias@libc.org>]

On Wed, Jun 21, 2023 at 02:10:50PM +0800, 罗勇刚(Yonggang Luo) wrote:
> On Wed, Jun 21, 2023 at 6:47 AM Rich Felker <dalias@libc.org> wrote:
> >
> > On Tue, Jun 20, 2023 at 10:36:58PM +0800, Yonggang Luo wrote:
> > > Currently, musl doesn't have pthread_mutex_clocklock
> pthread_cond_clockdwait, but
> > > glibc, android bionic, qnx libc already have these two functions, so
> implement them in
> > > musl.
> > >
> > > And for c11 threads, the mtx and cnd doesn't support for monotonic
> timedlock and timedwait;
> > > So add a proposaled function mtx_timedlock_base cnd_timedwait_base to
> do that.
> > > The protype of these two functions is:
> > > int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct
> timespec *restrict ts);
> > > int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
> time_base, const struct timespec *restrict ts);
> > > The time_base at least can be TIME_UTC/TIME_MONOTONIC, the implementer
> can implement it with any provided
> > > TIME_* base parameter provided in c2y time.h, if TIME_MONOTONIC can not
> natively supported, fallback to TIME_UTC
> > > should provided, for other TIME_* base parameter, it's implementer's
> choice.
> > >
> > > And indeed mtx_timedlock_base and cnd_timedwait_base  can be
> implemented ontop of
> > > posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait, so I
> implemented
> > > posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait first in
> musl.
> >
> > Implementation of any function in this family is contingent on
> > standardization; musl won't add things in a namespace likely to
> > conflict with future standardization that's not at least already very
> > far along the road to being standardized.
> >
> > I believe the corresponding pthread functions are already on that
> > path, but the c11-thread-api ones afaik aren't. Adding support for the
> > former was raised in the past, and the concern was that it may be
> 
> Do you means the pthread functions is already on the way? where is it and

It was proposed for standardization as Austin Group issue 1216 -
http://austingroupbugs.net/view.php?id=1216 - and approved for
inclusion in future versions of the standard. This means it's pretty
much automatically something that qualifies for inclusion in musl, so
it's a TODO item that just hasn't been done yet.

> > adding an extra cost to the existing functions most callers actually
> > want to use for the sake of a fringe need, in terms of an extra call
> > frame layer. That can probably be mitigated by lifting the initial
> > trylock, but doing this in a way that's not a mess and doesn't
> 
> We can use always_inline to avoid that.

No, because these are separate TUs. But even if you put them in the
same TU to do it, doubling the code size of each affected function is
not really desirable. Doing that for a single function or small set of
functions wouldn't really matter, but as a policy it's not done in
musl because if you did it for *every* function that might potentially
benefit, the size (and likely performance due to icache considerations
etc.) cost would be quite high.

At first I thought lifting the trylock but otherwise calling thru to
the "most general form" (clocklock) was probably the right way to do
it, but it might just make sense to change lock to call clocklock
directly instead of calling timedlock and having that in turn call
clocklock. This way the number of call levels is unchanged for normal
lock operations, only increased for the classic timedlock.

Rich