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=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17790 invoked from network); 21 Jun 2023 14:54:43 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Jun 2023 14:54:43 -0000 Received: (qmail 9696 invoked by uid 550); 21 Jun 2023 14:54:40 -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 9651 invoked from network); 21 Jun 2023 14:54:38 -0000 Date: Wed, 21 Jun 2023 10:54:27 -0400 From: Rich Felker To: =?utf-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= Cc: Jens Gustedt , enh , musl@lists.openwall.com Message-ID: <20230621145427.GK4163@brightrain.aerifal.cx> References: <20230620143703.1415-1-luoyonggang@gmail.com> <20230620224704.GI4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base On Wed, Jun 21, 2023 at 02:10:50PM +0800, 罗勇刚(Yonggang Luo) wrote: > On Wed, Jun 21, 2023 at 6:47 AM 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 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