On Wed, Jun 21, 2023 at 10:54 PM Rich Felker <dalias@libc.org> wrote:
>
> 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

What's is TUs, sorry I can not understand it

> 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



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo