From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28049 invoked from network); 21 Jun 2023 18:58:56 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Jun 2023 18:58:56 -0000 Received: (qmail 19947 invoked by uid 550); 21 Jun 2023 18:58:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19914 invoked from network); 21 Jun 2023 18:58:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687373920; x=1689965920; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IxquCovAg8D1Qu+3LEnSheFG23XMEvZ5s28pgF4lk1E=; b=pAJmVdF4XA/lOufOJP8hbkk0SAOqect5f1/X+fmkBd0pa17t9C4uucbhEpqKmat1jH 8WEcjVU78G0Xrz1DV89eFkXOdyP5lii2zrkD0M0xH/zV5czZ/P6LHM2m3SJ4Qz4gzPKZ m7zhlzNQD+SCKIvtyKzCPVahVcKJx0JRxlP4gmjHvFK0zrhCJpDd4t9Bp8L4h65s4Gia ztGX5BX2C0XkMFrDn50pLtV6EXRMNYWvbEPQr+nI/d503X+hbnxGBMOmgno3Geliyd1C x3ba/6RPkLq65ylp4f9DDyjm4vNKZPBsoccZYUtRhtiUg5kgmHkh2M8OH63BIbyE5lmT QmAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687373920; x=1689965920; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IxquCovAg8D1Qu+3LEnSheFG23XMEvZ5s28pgF4lk1E=; b=j/lX0Qjw99n0/Hz0007QS6r/su4jFUVIu+10bKRwvULYtvUpc9cbtOx+tSxhrPQLmX SmRvLy14G5ojpCMQr581I4RYrTLCuP7dvHQ1ZK4zHqbmDe2LB2V6ZNIUWky2WB0oFHpL 7IAC7KkfR+socAlfhzbY2b+QOEB+dUcYpw2+nWE0JY1oKdEsFBA1qq9rITS6lOB1vG42 Tiwe2+slfgorekutOwkB950zyjL5n0LYdeSmH2eaQNeygKzypSiCzqrsfoLRwThHTj1F FTcoppKO7GXSumrlzmBAWu53hu6QL9K8tuZppvRxAXxuwXdWMq9nyZe1e/uPIrSsEyV8 TRVg== X-Gm-Message-State: AC+VfDy4SBoM7+axBs0EX1jNCnuhqnXJSUwUMbp1nyXXEqNKKqs7x59b oQMdKvMUAnri4Sr/1Xaq/gvfGmI6l8TQTnX8wCowPg== X-Google-Smtp-Source: ACHHUZ4hcg66EdpSOF3rZV2x+oC9oCBBryPP1TZyo43lDpyXfzhYllcco9AXPpcRr+MpEPmm2xBGzgX2fr8CgoU2DNY= X-Received: by 2002:a05:6214:48a:b0:62f:eff9:1b8b with SMTP id pt10-20020a056214048a00b0062feff91b8bmr23671767qvb.31.1687373919766; Wed, 21 Jun 2023 11:58:39 -0700 (PDT) MIME-Version: 1.0 References: <20230620143703.1415-1-luoyonggang@gmail.com> <20230620224704.GI4163@brightrain.aerifal.cx> <20230621145427.GK4163@brightrain.aerifal.cx> In-Reply-To: From: enh Date: Wed, 21 Jun 2023 11:58:28 -0700 Message-ID: To: luoyonggang@gmail.com Cc: Rich Felker , Jens Gustedt , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000179ec005fea85b59" Subject: Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base --000000000000179ec005fea85b59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM =E7=BD=97=E5=8B=87=E5=88=9A(Yongga= ng Luo) wrote: > > > On Wed, Jun 21, 2023 at 10:54=E2=80=AFPM Rich Felker wr= ote: > > > > On Wed, Jun 21, 2023 at 02:10:50PM +0800, =E7=BD=97=E5=8B=87=E5=88=9A(Y= onggang Luo) wrote: > > > On Wed, Jun 21, 2023 at 6:47=E2=80=AFAM Rich Felker = 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 monotoni= c > > > timedlock and timedwait; > > > > > So add a proposaled function mtx_timedlock_base cnd_timedwait_bas= e > 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 ve= ry > > > > 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=3D1216 - 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 actuall= y > > > > want to use for the sake of a fringe need, in terms of an extra cal= l > > > > 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 > > > > -- > =E6=AD=A4=E8=87=B4 > =E7=A4=BC > =E7=BD=97=E5=8B=87=E5=88=9A > Yours > sincerely, > Yonggang Luo > --000000000000179ec005fea85b59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TU is an abbreviation of a term used in the C standard: http= s://en.wikipedia.org/wiki/Translation_unit_(programming)=C2=A0

On We= d, Jun 21, 2023 at 11:44=E2=80=AFAM =E7=BD=97=E5=8B=87=E5=88=9A(Yonggang Lu= o) <luoyonggang@gmail.com&g= t; wrote:


On Wed, Jun 21, 2023 at 10:54=E2=80=AFPM Rich Felker <= ;dalias@libc.org&g= t; wrote:
>
> On Wed, Jun 21, 2023 at 02:10:50PM +0800, =E7=BD= =97=E5=8B=87=E5=88=9A(Yonggang Luo) wrote:
> > On Wed, Jun 21, 202= 3 at 6:47=E2=80=AFAM 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, andr= oid bionic, qnx libc already have these two functions, so
> > impl= ement them in
> > > > musl.
> > > >
> &= gt; > > And for c11 threads, the mtx and cnd doesn't support for = monotonic
> > timedlock and timedwait;
> > > > So a= dd a proposaled function mtx_timedlock_base cnd_timedwait_base to
> &= gt; do that.
> > > > The protype of these two functions is:<= br>> > > > int mtx_timedlock_base(mtx_t *restrict m, int time_b= ase, const struct
> > timespec *restrict ts);
> > > &g= t; 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
> &= gt; natively supported, fallback to TIME_UTC
> > > > should = provided, for other TIME_* base parameter, it's implementer's
&g= t; > choice.
> > > >
> > > > And indeed mt= x_timedlock_base and cnd_timedwait_base =C2=A0can be
> > implement= ed ontop of
> > > > posix/pthread_mutex_clocklock posix/pthr= ead_cond_clockdwait, so I
> > implemented
> > > > p= osix/pthread_mutex_clocklock posix/pthread_cond_clockdwait first in
>= > musl.
> > >
> > > Implementation of any funct= ion in this family is contingent on
> > > standardization; musl= won't add things in a namespace likely to
> > > conflict w= ith 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. Addi= ng support for the
> > > former was raised in the past, and the= concern was that it may be
> >
> > Do you means the pthr= ead 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=3D1216 - and approved for
> incl= usion 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.
>
&g= t; > > adding an extra cost to the existing functions most callers ac= tually
> > > want to use for the sake of a fringe need, in term= s of an extra call
> > > frame layer. That can probably be miti= gated 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 sep= arate TUs. But even if you put them in the

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

> same TU to do it, do= ubling the code size of each affected function is
> not really desira= ble. Doing that for a single function or small set of
> functions wou= ldn't really matter, but as a policy it's not done in
> musl = because if you did it for *every* function that might potentially
> b= enefit, the size (and likely performance due to icache considerations
&g= t; etc.) cost would be quite high.
>
> At first I thought lifti= ng 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 in= stead of calling timedlock and having that in turn call
> clocklock. = This way the number of call levels is unchanged for normal
> lock ope= rations, only increased for the classic timedlock.
>
> Rich
=


--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E6=AD=A4=E8=87=B4
= =E7=A4=BC
=E7=BD=97=E5=8B=87=E5=88=9A
Yours
=C2=A0 =C2=A0 sincerel= y,
Yonggang Luo
--000000000000179ec005fea85b59--