[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 21 Jun 2023 11:58:28 -0700
From: enh <enh@...gle.com>
To: luoyonggang@...il.com
Cc: Rich Felker <dalias@...c.org>, Jens Gustedt <jens.gustedt@...ia.fr>, musl@...ts.openwall.com
Subject: Re: [PATCH v3 0/5] Add posix/pthread_mutex_clocklock
posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base
TU is an abbreviation of a term used in the C standard:
https://en.wikipedia.org/wiki/Translation_unit_(programming)
On Wed, Jun 21, 2023 at 11:44 AM 罗勇刚(Yonggang Luo) <luoyonggang@...il.com>
wrote:
>
>
> On Wed, Jun 21, 2023 at 10:54 PM Rich Felker <dalias@...c.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@...c.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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
