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,FREEMAIL_FROM,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 27318 invoked from network); 21 Jun 2023 18:44:21 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Jun 2023 18:44:21 -0000 Received: (qmail 5247 invoked by uid 550); 21 Jun 2023 18:44:18 -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 5208 invoked from network); 21 Jun 2023 18:44:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687373046; x=1689965046; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nLt7xscxeElLYiFILLzzLBImOptOLFzFdIUxrriSQrQ=; b=Iq3Xx+pgTBavq8KwLft4QfIdv2ZTsJkJ3N0LMyFvneoVdcGHLyTCLO6qMyrrViUsOT P20tKcmLd+iGek1SyhycLA19zDNaoKxZO9yZVTkxN3lGwBsKHvtwO1BzEpj/iu7FJH4b 1qkDW7e4vH3zS6i71oBV9kY4t55xXoFkjpqX3w61gOSLQD5jgOzHFAEskLw0IG15Dxu9 PgBiiDDAqyJQgoc5GRg7BksLeAk1wzJZvS/U2+vReo55IV3BWXt22QgP7CzyFtk4Bjgy crI6pZc6YBcMl33L8a47JnV+yCFJpOdlNjeVrgmPB6JhPiokPc3c8iFtytIMNHqXTcmy 549w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687373046; x=1689965046; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nLt7xscxeElLYiFILLzzLBImOptOLFzFdIUxrriSQrQ=; b=NiM6fBuioun/pHQDWgn8ialXNQyvUkfAtayO0aYJh8NI/8E57mYYikOf6FD1WN6mZe wefATICSpSZGuzxSEKjcZBkg1a0hRWgg3+k0ecVBOS9X/eYPryPbMaXVwFWMINCDn5QU 0ZHvTS7R9ht/ZPTDckSz68xhDKw9z6qeEnsdkmHsi/E19g+wvOAJZdp7IzYs5Y+4XemT yQvzOW3At1mzjwiMa2trZaz1JdcLBCj1x6+5JjXLkTEa8NanzqnfmfRKnIj50CRLYUE9 /jnGn65fQqIfy93qNNQwFmDJgXslZnqELM3G3L1x5UadtYmCiyAuSgG6ZeinrOzLd00j /AZA== X-Gm-Message-State: AC+VfDzrtYHdIiURzZSYYo9QOtM1/aBzD56ldlXCN8tp2EzaRykA010J 0O0l4XWVZurXpAKzqwLharNd0bTVwc7t5I7zMmc= X-Google-Smtp-Source: ACHHUZ5cooFu9/+bz/4znekm1jcQWLbkCQupQypR5J+qrt2MhfQalKmFb8NilIZ1x2FPA2XHZfpd1XcluJEShi/qGd0= X-Received: by 2002:a17:907:9624:b0:987:9852:603a with SMTP id gb36-20020a170907962400b009879852603amr14418757ejc.26.1687373045453; Wed, 21 Jun 2023 11:44:05 -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: <20230621145427.GK4163@brightrain.aerifal.cx> From: =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= Date: Thu, 22 Jun 2023 02:43:54 +0800 Message-ID: To: Rich Felker Cc: Jens Gustedt , enh , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000fa564805fea826ea" Subject: Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base --000000000000fa564805fea826ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 21, 2023 at 10:54=E2=80=AFPM Rich Felker wrot= e: > > On Wed, Jun 21, 2023 at 02:10:50PM +0800, =E7=BD=97=E5=8B=87=E5=88=9A(Yon= ggang Luo) wrote: > > On Wed, Jun 21, 2023 at 6:47=E2=80=AFAM Rich Felker w= rote: > > > > > > 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, s= o > > 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 i= n > > 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 th= e > > > 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 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 -- =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo --000000000000fa564805fea826ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 21, 2023 at 10:54=E2=80=AFPM Rich Felk= er <dalias@libc.org> 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, 2023 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, mu= sl doesn't have pthread_mutex_clocklock
> > pthread_cond_clock= dwait, but
> > > > glibc, android bionic, qnx libc already h= ave these two functions, so
> > implement them in
> > >= ; > musl.
> > > >
> > > > And for c11 thre= ads, the mtx and cnd doesn't support for monotonic
> > timedlo= ck and timedwait;
> > > > So add a proposaled function mtx_t= imedlock_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 b= e TIME_UTC/TIME_MONOTONIC, the implementer
> > can implement it wi= th any provided
> > > > TIME_* base parameter provided in c2= y time.h, if TIME_MONOTONIC can not
> > natively supported, fallba= ck to TIME_UTC
> > > > should provided, for other TIME_* bas= e parameter, it's implementer's
> > choice.
> > &= gt; >
> > > > And indeed mtx_timedlock_base and cnd_timed= wait_base =C2=A0can be
> > implemented ontop of
> > > = > posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait, so I
&= gt; > implemented
> > > > posix/pthread_mutex_clocklock p= osix/pthread_cond_clockdwait first in
> > musl.
> > ><= br>> > > Implementation of any function in this family is continge= nt on
> > > standardization; musl won't add things in a nam= espace likely to
> > > conflict with future standardization tha= t's not at least already very
> > > far along the road to b= eing standardized.
> > >
> > > I believe the corres= ponding pthread functions are already on that
> > > path, but t= he 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 th= e 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 me= ans it's pretty
> much automatically something that qualifies for= inclusion in musl, so
> it's a TODO item that just hasn't be= en 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
> > > tr= ylock, 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 se= t 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 m= ight potentially
> benefit, the size (and likely performance due to i= cache considerations
> etc.) cost would be quite high.
>
>= ; At first I thought lifting the trylock but otherwise calling thru to
&= gt; the "most general form" (clocklock) was probably the right wa= y to do
> it, but it might just make sense to change lock to call clo= cklock
> directly instead of calling timedlock and having that in tur= n call
> clocklock. This way the number of call levels is unchanged f= or normal
> lock operations, 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<= br>=C2=A0 =C2=A0 sincerely,
Yonggang Luo
--000000000000fa564805fea826ea--