[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2023 18:47:04 -0400
From: Rich Felker <dalias@...c.org>
To: Yonggang Luo <luoyonggang@...il.com>
Cc: Jens Gustedt <jens.gustedt@...ia.fr>, enh <enh@...gle.com>,
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
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
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
gratuitously repeat trylocks isn't entirely trivial.
> I think mtx_timedlock_base cnd_timedwait_base is reasonable because it's newly added
> function and won't affect existing c11 threads functions.
> And it's can be implementd with glibc/qnx libc/android bionic without burden.
> For OS X it's can be implemented with pthread_cond_timedwait_relative_np
> For Windows it's can be implemented with SleepConditionVariableCS
> For platform have none of these, it's still can fallback to using mtx_timedlock and cnd_timedwait
> over TIME_UTC
>
> Yonggang Luo (5):
> trim spaces of pthread_cond_timedwait.c and pthread_mutex_timedlock.c
> Rename files for implement pthread_mutex_clocklock and
> pthread_cond_clockwait
> add pthread_mutex_clocklock and pthread_cond_clockdwait
> c23: Implement newly base for timespec_get
> c2y: Add monotonic timedlock/timedwait support for threads mtx/cnd
As a general principle, please groups of associated patches to this
list as a single mail with the individual patches as MIME attachments,
not LKML-style as a giant thread with one message per patch. This is
to:
- avoid flooding the inboxes of list subscribers
- facilitate discussion/replies that involve more than one patch in
the series
- allow revisions to be easily introduced in the existing thread for a
topic rather than starting a new one each time there's a revision.
Rich
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.
