[musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[Yonggang Luo]

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.

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

 compat/time32/cnd_timedwait_base_time32.c     |   9 +
 compat/time32/mtx_timedlock_base_time32.c     |   9 +
 compat/time32/pthread_cond_clockwait_time32.c |   9 +
 .../time32/pthread_mutex_clocklock_time32.c   |   9 +
 compat/time32/time32.h                        |   4 +
 include/pthread.h                             |   4 +
 include/threads.h                             |   4 +
 include/time.h                                |  13 +-
 src/include/pthread.h                         |   2 +
 src/thread/cnd_timedwait.c                    |   8 +-
 src/thread/cnd_timedwait_base.c               |  26 +++
 src/thread/mtx_timedlock.c                    |   7 +-
 src/thread/mtx_timedlock_base.c               |  25 +++
 ...d_timedwait.c => pthread_cond_clockwait.c} |  14 +-
 src/thread/pthread_cond_timedwait.c           | 208 +-----------------
 ..._timedlock.c => pthread_mutex_clocklock.c} |  14 +-
 src/thread/pthread_mutex_timedlock.c          |  86 +-------
 src/time/timespec_get.c                       |  44 +++-
 18 files changed, 174 insertions(+), 321 deletions(-)
 create mode 100644 compat/time32/cnd_timedwait_base_time32.c
 create mode 100644 compat/time32/mtx_timedlock_base_time32.c
 create mode 100644 compat/time32/pthread_cond_clockwait_time32.c
 create mode 100644 compat/time32/pthread_mutex_clocklock_time32.c
 create mode 100644 src/thread/cnd_timedwait_base.c
 create mode 100644 src/thread/mtx_timedlock_base.c
 copy src/thread/{pthread_cond_timedwait.c => pthread_cond_clockwait.c} (93%)
 copy src/thread/{pthread_mutex_timedlock.c => pthread_mutex_clocklock.c} (85%)

-- 
2.39.0.windows.1

[musl] [PATCH v3 1/5] trim spaces of pthread_cond_timedwait.c and pthread_mutex_timedlock.c

[Yonggang Luo]

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 src/thread/pthread_cond_timedwait.c  | 6 +++---
 src/thread/pthread_mutex_timedlock.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/thread/pthread_cond_timedwait.c b/src/thread/pthread_cond_timedwait.c
index 6b761455..c5b35a6c 100644
--- a/src/thread/pthread_cond_timedwait.c
+++ b/src/thread/pthread_cond_timedwait.c
@@ -121,12 +121,12 @@ int __pthread_cond_timedwait(pthread_cond_t *restrict c, pthread_mutex_t *restri
 		 * via the futex notify below. */
 
 		lock(&c->_c_lock);
-		
+
 		if (c->_c_head == &node) c->_c_head = node.next;
 		else if (node.prev) node.prev->next = node.next;
 		if (c->_c_tail == &node) c->_c_tail = node.prev;
 		else if (node.next) node.next->prev = node.prev;
-		
+
 		unlock(&c->_c_lock);
 
 		if (node.notify) {
@@ -156,7 +156,7 @@ relock:
 		if (val>0) a_cas(&m->_m_lock, val, val|0x80000000);
 		unlock_requeue(&node.prev->barrier, &m->_m_lock, m->_m_type & (8|128));
 	} else if (!(m->_m_type & 8)) {
-		a_dec(&m->_m_waiters);		
+		a_dec(&m->_m_waiters);
 	}
 
 	/* Since a signal was consumed, cancellation is not permitted. */
diff --git a/src/thread/pthread_mutex_timedlock.c b/src/thread/pthread_mutex_timedlock.c
index 9279fc54..87f89287 100644
--- a/src/thread/pthread_mutex_timedlock.c
+++ b/src/thread/pthread_mutex_timedlock.c
@@ -66,7 +66,7 @@ int __pthread_mutex_timedlock(pthread_mutex_t *restrict m, const struct timespec
 	if (r != EBUSY) return r;
 
 	if (type&8) return pthread_mutex_timedlock_pi(m, at);
-	
+
 	int spins = 100;
 	while (spins-- && m->_m_lock && !m->_m_waiters) a_spin();
 
-- 
2.39.0.windows.1

[musl] [PATCH v3 2/5] Rename files for implement pthread_mutex_clocklock and pthread_cond_clockwait

[Yonggang Luo]

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 src/thread/{pthread_cond_timedwait.c => pthread_cond_clockwait.c} | 0
 .../{pthread_mutex_timedlock.c => pthread_mutex_clocklock.c}      | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename src/thread/{pthread_cond_timedwait.c => pthread_cond_clockwait.c} (100%)
 rename src/thread/{pthread_mutex_timedlock.c => pthread_mutex_clocklock.c} (100%)

diff --git a/src/thread/pthread_cond_timedwait.c b/src/thread/pthread_cond_clockwait.c
similarity index 100%
rename from src/thread/pthread_cond_timedwait.c
rename to src/thread/pthread_cond_clockwait.c
diff --git a/src/thread/pthread_mutex_timedlock.c b/src/thread/pthread_mutex_clocklock.c
similarity index 100%
rename from src/thread/pthread_mutex_timedlock.c
rename to src/thread/pthread_mutex_clocklock.c
-- 
2.39.0.windows.1

[musl] [PATCH v3 3/5] add pthread_mutex_clocklock and pthread_cond_clockdwait

[Yonggang Luo]

These two functions are already implemented in glibc, android bionic libc, qnx libc

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 compat/time32/pthread_cond_clockwait_time32.c  |  9 +++++++++
 compat/time32/pthread_mutex_clocklock_time32.c |  9 +++++++++
 compat/time32/time32.h                         |  2 ++
 include/pthread.h                              |  4 ++++
 src/include/pthread.h                          |  2 ++
 src/thread/pthread_cond_clockwait.c            |  8 ++++----
 src/thread/pthread_cond_timedwait.c            |  9 +++++++++
 src/thread/pthread_mutex_clocklock.c           | 12 ++++++------
 src/thread/pthread_mutex_timedlock.c           |  8 ++++++++
 9 files changed, 53 insertions(+), 10 deletions(-)
 create mode 100644 compat/time32/pthread_cond_clockwait_time32.c
 create mode 100644 compat/time32/pthread_mutex_clocklock_time32.c
 create mode 100644 src/thread/pthread_cond_timedwait.c
 create mode 100644 src/thread/pthread_mutex_timedlock.c

diff --git a/compat/time32/pthread_cond_clockwait_time32.c b/compat/time32/pthread_cond_clockwait_time32.c
new file mode 100644
index 00000000..615473b1
--- /dev/null
+++ b/compat/time32/pthread_cond_clockwait_time32.c
@@ -0,0 +1,9 @@
+#include "time32.h"
+#include <time.h>
+#include <pthread.h>
+
+int __pthread_cond_clockwait_time32(pthread_cond_t *restrict c, pthread_mutex_t *restrict m, clockid_t clock, const struct timespec32 *restrict ts32)
+{
+	return pthread_cond_clockwait(c, m, clock, !ts32 ? 0 : (&(struct timespec){
+		.tv_sec = ts32->tv_sec, .tv_nsec = ts32->tv_nsec}));
+}
diff --git a/compat/time32/pthread_mutex_clocklock_time32.c b/compat/time32/pthread_mutex_clocklock_time32.c
new file mode 100644
index 00000000..d54e85a7
--- /dev/null
+++ b/compat/time32/pthread_mutex_clocklock_time32.c
@@ -0,0 +1,9 @@
+#include "time32.h"
+#include <time.h>
+#include <pthread.h>
+
+int __pthread_mutex_clocklock_time32(pthread_mutex_t *restrict m, clockid_t clk, const struct timespec32 *restrict ts32)
+{
+	return pthread_mutex_clocklock(m, clk, !ts32 ? 0 : (&(struct timespec){
+		.tv_sec = ts32->tv_sec, .tv_nsec = ts32->tv_nsec}));
+}
diff --git a/compat/time32/time32.h b/compat/time32/time32.h
index fdec17c3..1267f255 100644
--- a/compat/time32/time32.h
+++ b/compat/time32/time32.h
@@ -59,7 +59,9 @@ int __mtx_timedlock_time32() __asm__("mtx_timedlock");
 int __nanosleep_time32() __asm__("nanosleep");
 int __ppoll_time32() __asm__("ppoll");
 int __pselect_time32() __asm__("pselect");
+int __pthread_cond_clockwait_time32() __asm__("pthread_cond_clockwait");
 int __pthread_cond_timedwait_time32() __asm__("pthread_cond_timedwait");
+int __pthread_mutex_clocklock_time32() __asm__("pthread_mutex_clocklock");
 int __pthread_mutex_timedlock_time32() __asm__("pthread_mutex_timedlock");
 int __pthread_rwlock_timedrdlock_time32() __asm__("pthread_rwlock_timedrdlock");
 int __pthread_rwlock_timedwrlock_time32() __asm__("pthread_rwlock_timedwrlock");
diff --git a/include/pthread.h b/include/pthread.h
index 89fd9ff7..7fb2d162 100644
--- a/include/pthread.h
+++ b/include/pthread.h
@@ -107,6 +107,7 @@ int pthread_mutex_init(pthread_mutex_t *__restrict, const pthread_mutexattr_t *_
 int pthread_mutex_lock(pthread_mutex_t *);
 int pthread_mutex_unlock(pthread_mutex_t *);
 int pthread_mutex_trylock(pthread_mutex_t *);
+int pthread_mutex_clocklock(pthread_mutex_t *__restrict, clockid_t, const struct timespec *__restrict);
 int pthread_mutex_timedlock(pthread_mutex_t *__restrict, const struct timespec *__restrict);
 int pthread_mutex_destroy(pthread_mutex_t *);
 int pthread_mutex_consistent(pthread_mutex_t *);
@@ -117,6 +118,7 @@ int pthread_mutex_setprioceiling(pthread_mutex_t *__restrict, int, int *__restri
 int pthread_cond_init(pthread_cond_t *__restrict, const pthread_condattr_t *__restrict);
 int pthread_cond_destroy(pthread_cond_t *);
 int pthread_cond_wait(pthread_cond_t *__restrict, pthread_mutex_t *__restrict);
+int pthread_cond_clockwait(pthread_cond_t *__restrict, pthread_mutex_t *__restrict, clockid_t, const struct timespec *__restrict);
 int pthread_cond_timedwait(pthread_cond_t *__restrict, pthread_mutex_t *__restrict, const struct timespec *__restrict);
 int pthread_cond_broadcast(pthread_cond_t *);
 int pthread_cond_signal(pthread_cond_t *);
@@ -229,7 +231,9 @@ int pthread_timedjoin_np(pthread_t, void **, const struct timespec *);
 #endif
 
 #if _REDIR_TIME64
+__REDIR(pthread_mutex_clocklock, __pthread_mutex_clocklock_time64);
 __REDIR(pthread_mutex_timedlock, __pthread_mutex_timedlock_time64);
+__REDIR(pthread_cond_clockwait, __pthread_cond_clockwait_time64);
 __REDIR(pthread_cond_timedwait, __pthread_cond_timedwait_time64);
 __REDIR(pthread_rwlock_timedrdlock, __pthread_rwlock_timedrdlock_time64);
 __REDIR(pthread_rwlock_timedwrlock, __pthread_rwlock_timedwrlock_time64);
diff --git a/src/include/pthread.h b/src/include/pthread.h
index 7167d3e1..d7fe7974 100644
--- a/src/include/pthread.h
+++ b/src/include/pthread.h
@@ -12,9 +12,11 @@ hidden int __pthread_join(pthread_t, void **);
 hidden int __pthread_mutex_lock(pthread_mutex_t *);
 hidden int __pthread_mutex_trylock(pthread_mutex_t *);
 hidden int __pthread_mutex_trylock_owner(pthread_mutex_t *);
+hidden int __pthread_mutex_clocklock(pthread_mutex_t *restrict, clockid_t, const struct timespec *restrict);
 hidden int __pthread_mutex_timedlock(pthread_mutex_t *restrict, const struct timespec *restrict);
 hidden int __pthread_mutex_unlock(pthread_mutex_t *);
 hidden int __private_cond_signal(pthread_cond_t *, int);
+hidden int __pthread_cond_clockwait(pthread_cond_t *restrict, pthread_mutex_t *restrict, clockid_t, const struct timespec *restrict);
 hidden int __pthread_cond_timedwait(pthread_cond_t *restrict, pthread_mutex_t *restrict, const struct timespec *restrict);
 hidden int __pthread_key_create(pthread_key_t *, void (*)(void *));
 hidden int __pthread_key_delete(pthread_key_t);
diff --git a/src/thread/pthread_cond_clockwait.c b/src/thread/pthread_cond_clockwait.c
index c5b35a6c..4d178c27 100644
--- a/src/thread/pthread_cond_clockwait.c
+++ b/src/thread/pthread_cond_clockwait.c
@@ -59,10 +59,10 @@ enum {
 	LEAVING,
 };
 
-int __pthread_cond_timedwait(pthread_cond_t *restrict c, pthread_mutex_t *restrict m, const struct timespec *restrict ts)
+int __pthread_cond_clockwait(pthread_cond_t *restrict c, pthread_mutex_t *restrict m, clockid_t clk, const struct timespec *restrict ts)
 {
 	struct waiter node = { 0 };
-	int e, seq, clock = c->_c_clock, cs, shared=0, oldstate, tmp;
+	int e, seq, cs, shared=0, oldstate, tmp;
 	volatile int *fut;
 
 	if ((m->_m_type&15) && (m->_m_lock&INT_MAX) != __pthread_self()->tid)
@@ -97,7 +97,7 @@ int __pthread_cond_timedwait(pthread_cond_t *restrict c, pthread_mutex_t *restri
 	__pthread_setcancelstate(PTHREAD_CANCEL_MASKED, &cs);
 	if (cs == PTHREAD_CANCEL_DISABLE) __pthread_setcancelstate(cs, 0);
 
-	do e = __timedwait_cp(fut, seq, clock, ts, !shared);
+	do e = __timedwait_cp(fut, seq, clk, ts, !shared);
 	while (*fut==seq && (!e || e==EINTR));
 	if (e == EINTR) e = 0;
 
@@ -210,4 +210,4 @@ int __private_cond_signal(pthread_cond_t *c, int n)
 	return 0;
 }
 
-weak_alias(__pthread_cond_timedwait, pthread_cond_timedwait);
+weak_alias(__pthread_cond_clockwait, pthread_cond_clockwait);
diff --git a/src/thread/pthread_cond_timedwait.c b/src/thread/pthread_cond_timedwait.c
new file mode 100644
index 00000000..da803df7
--- /dev/null
+++ b/src/thread/pthread_cond_timedwait.c
@@ -0,0 +1,9 @@
+#include "pthread_impl.h"
+
+int __pthread_cond_timedwait(pthread_cond_t *restrict c, pthread_mutex_t *restrict m, const struct timespec *restrict ts)
+{
+	int clock = c->_c_clock;
+	return __pthread_cond_clockwait(c, m, clock, ts);
+}
+
+weak_alias(__pthread_cond_timedwait, pthread_cond_timedwait);
diff --git a/src/thread/pthread_mutex_clocklock.c b/src/thread/pthread_mutex_clocklock.c
index 87f89287..4a0a945f 100644
--- a/src/thread/pthread_mutex_clocklock.c
+++ b/src/thread/pthread_mutex_clocklock.c
@@ -18,7 +18,7 @@ static int __futex4(volatile void *addr, int op, int val, const struct timespec
 	return __syscall(SYS_futex, addr, op, val, to);
 }
 
-static int pthread_mutex_timedlock_pi(pthread_mutex_t *restrict m, const struct timespec *restrict at)
+static int pthread_mutex_timedlock_pi(pthread_mutex_t *restrict m, clockid_t clk, const struct timespec *restrict at)
 {
 	int type = m->_m_type;
 	int priv = (type & 128) ^ 128;
@@ -48,12 +48,12 @@ static int pthread_mutex_timedlock_pi(pthread_mutex_t *restrict m, const struct
 	case EDEADLK:
 		if ((type&3) == PTHREAD_MUTEX_ERRORCHECK) return e;
 	}
-	do e = __timedwait(&(int){0}, 0, CLOCK_REALTIME, at, 1);
+	do e = __timedwait(&(int){0}, 0, clk, at, 1);
 	while (e != ETIMEDOUT);
 	return e;
 }
 
-int __pthread_mutex_timedlock(pthread_mutex_t *restrict m, const struct timespec *restrict at)
+int __pthread_mutex_clocklock(pthread_mutex_t *restrict m, clockid_t clk, const struct timespec *restrict at)
 {
 	if ((m->_m_type&15) == PTHREAD_MUTEX_NORMAL
 	    && !a_cas(&m->_m_lock, 0, EBUSY))
@@ -65,7 +65,7 @@ int __pthread_mutex_timedlock(pthread_mutex_t *restrict m, const struct timespec
 	r = __pthread_mutex_trylock(m);
 	if (r != EBUSY) return r;
 
-	if (type&8) return pthread_mutex_timedlock_pi(m, at);
+	if (type&8) return pthread_mutex_timedlock_pi(m, clk, at);
 
 	int spins = 100;
 	while (spins-- && m->_m_lock && !m->_m_waiters) a_spin();
@@ -82,11 +82,11 @@ int __pthread_mutex_timedlock(pthread_mutex_t *restrict m, const struct timespec
 		a_inc(&m->_m_waiters);
 		t = r | 0x80000000;
 		a_cas(&m->_m_lock, r, t);
-		r = __timedwait(&m->_m_lock, t, CLOCK_REALTIME, at, priv);
+		r = __timedwait(&m->_m_lock, t, clk, at, priv);
 		a_dec(&m->_m_waiters);
 		if (r && r != EINTR) break;
 	}
 	return r;
 }
 
-weak_alias(__pthread_mutex_timedlock, pthread_mutex_timedlock);
+weak_alias(__pthread_mutex_clocklock, pthread_mutex_clocklock);
diff --git a/src/thread/pthread_mutex_timedlock.c b/src/thread/pthread_mutex_timedlock.c
new file mode 100644
index 00000000..14a87065
--- /dev/null
+++ b/src/thread/pthread_mutex_timedlock.c
@@ -0,0 +1,8 @@
+#include "pthread_impl.h"
+
+int __pthread_mutex_timedlock(pthread_mutex_t *restrict m, const struct timespec *restrict at)
+{
+	return __pthread_mutex_clocklock(m, CLOCK_REALTIME, at);
+}
+
+weak_alias(__pthread_mutex_timedlock, pthread_mutex_timedlock);
-- 
2.39.0.windows.1

Re: [musl] [PATCH v3 3/5] add pthread_mutex_clocklock and pthread_cond_clockdwait

[Rich Felker]

On Tue, Jun 20, 2023 at 10:37:01PM +0800, Yonggang Luo wrote:
> These two functions are already implemented in glibc, android bionic libc, qnx libc
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> ---
>  compat/time32/pthread_cond_clockwait_time32.c  |  9 +++++++++
>  compat/time32/pthread_mutex_clocklock_time32.c |  9 +++++++++
>  compat/time32/time32.h                         |  2 ++
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

...

> --- a/include/pthread.h
> +++ b/include/pthread.h
> [...]
>  
>  #if _REDIR_TIME64
> +__REDIR(pthread_mutex_clocklock, __pthread_mutex_clocklock_time64);
>  __REDIR(pthread_mutex_timedlock, __pthread_mutex_timedlock_time64);
> +__REDIR(pthread_cond_clockwait, __pthread_cond_clockwait_time64);

None of this is needed. There only exist redirections and legacy
time32 functions for symbols which existed in the ABI with 32-bit
time_t. Any newly added functions are time64 from day one.

Rich

[musl] [PATCH v3 4/5] c23: Implement newly base for timespec_get

[Yonggang Luo]

These are implemented https://gustedt.gitlabpages.inria.fr/c23-library/#time_monotonic-time_active-time_thread_active

with:

#define TIME_UTC                1
#define TIME_MONOTONIC          2
#define TIME_ACTIVE             3
#define TIME_THREAD_ACTIVE      4
#define TIME_MONOTONIC_RAW      5
#define TIME_UTC_COARSE         6
#define TIME_MONOTONIC_COARSE   7
#define TIME_BOOTTIME           8
#define TIME_UTC_ALARM          9
#define TIME_BOOTTIME_ALARM     10
#define TIME_SGI_CYCLE          11
#define TIME_TAI                12

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 include/time.h          | 13 +++++++++++-
 src/time/timespec_get.c | 44 +++++++++++++++++++++++++++++++++++++++--
 2 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/include/time.h b/include/time.h
index 3d948372..ab31d373 100644
--- a/include/time.h
+++ b/include/time.h
@@ -64,7 +64,18 @@ int timespec_get(struct timespec *, int);
 
 #define CLOCKS_PER_SEC 1000000L
 
-#define TIME_UTC 1
+#define TIME_UTC                1
+#define TIME_MONOTONIC          2
+#define TIME_ACTIVE             3
+#define TIME_THREAD_ACTIVE      4
+#define TIME_MONOTONIC_RAW      5
+#define TIME_UTC_COARSE         6
+#define TIME_MONOTONIC_COARSE   7
+#define TIME_BOOTTIME           8
+#define TIME_UTC_ALARM          9
+#define TIME_BOOTTIME_ALARM     10
+#define TIME_SGI_CYCLE          11
+#define TIME_TAI                12
 
 #if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
  || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) \
diff --git a/src/time/timespec_get.c b/src/time/timespec_get.c
index 40ea9c1c..b8738189 100644
--- a/src/time/timespec_get.c
+++ b/src/time/timespec_get.c
@@ -4,7 +4,47 @@
  * are considered erroneous. */
 int timespec_get(struct timespec * ts, int base)
 {
-	if (base != TIME_UTC) return 0;
-	int ret = __clock_gettime(CLOCK_REALTIME, ts);
+	clockid_t clockid = -1;
+	switch (base) {
+	default:
+		return 0;
+	case TIME_UTC:
+		clockid = CLOCK_REALTIME;
+		break;
+	case TIME_MONOTONIC:
+		clockid = CLOCK_MONOTONIC;
+		break;
+	case TIME_ACTIVE:
+		clockid = CLOCK_PROCESS_CPUTIME_ID;
+		break;
+	case TIME_THREAD_ACTIVE:
+		clockid = CLOCK_THREAD_CPUTIME_ID;
+		break;
+	case TIME_MONOTONIC_RAW:
+		clockid = CLOCK_MONOTONIC_RAW;
+		break;
+	case TIME_UTC_COARSE:
+		clockid = CLOCK_REALTIME_COARSE;
+		break;
+	case TIME_MONOTONIC_COARSE:
+		clockid = CLOCK_MONOTONIC_COARSE;
+		break;
+	case TIME_BOOTTIME:
+		clockid = CLOCK_BOOTTIME;
+		break;
+	case TIME_UTC_ALARM:
+		clockid = CLOCK_REALTIME_ALARM;
+		break;
+	case TIME_BOOTTIME_ALARM:
+		clockid = CLOCK_BOOTTIME_ALARM;
+		break;
+	case TIME_SGI_CYCLE:
+		clockid = CLOCK_SGI_CYCLE;
+		break;
+	case TIME_TAI:
+		clockid = CLOCK_TAI;
+		break;
+	}
+	int ret = __clock_gettime(clockid, ts);
 	return ret < 0 ? 0 : base;
 }
-- 
2.39.0.windows.1

[musl] [PATCH v3 5/5] c2y: Add monotonic timedlock/timedwait support for threads mtx/cnd

[Yonggang Luo]

Add two functions:
mtx_timedlock_base
cnd_timedwait_base

That support for both TIME_UTC and TIME_MONOTONIC

to achieve that

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 compat/time32/cnd_timedwait_base_time32.c |  9 ++++++++
 compat/time32/mtx_timedlock_base_time32.c |  9 ++++++++
 compat/time32/time32.h                    |  2 ++
 include/threads.h                         |  4 ++++
 src/thread/cnd_timedwait.c                |  8 +------
 src/thread/cnd_timedwait_base.c           | 26 +++++++++++++++++++++++
 src/thread/mtx_timedlock.c                |  7 +-----
 src/thread/mtx_timedlock_base.c           | 25 ++++++++++++++++++++++
 8 files changed, 77 insertions(+), 13 deletions(-)
 create mode 100644 compat/time32/cnd_timedwait_base_time32.c
 create mode 100644 compat/time32/mtx_timedlock_base_time32.c
 create mode 100644 src/thread/cnd_timedwait_base.c
 create mode 100644 src/thread/mtx_timedlock_base.c

diff --git a/compat/time32/cnd_timedwait_base_time32.c b/compat/time32/cnd_timedwait_base_time32.c
new file mode 100644
index 00000000..433f9841
--- /dev/null
+++ b/compat/time32/cnd_timedwait_base_time32.c
@@ -0,0 +1,9 @@
+#include "time32.h"
+#include <time.h>
+#include <threads.h>
+
+int __cnd_timedwait_base_time32(cnd_t *restrict c, mtx_t *restrict m, int time_base, const struct timespec32 *restrict ts32)
+{
+	return cnd_timedwait_base(c, m, time_base, ts32 ? (&(struct timespec){
+		.tv_sec = ts32->tv_sec, .tv_nsec = ts32->tv_nsec}) : 0);
+}
diff --git a/compat/time32/mtx_timedlock_base_time32.c b/compat/time32/mtx_timedlock_base_time32.c
new file mode 100644
index 00000000..8c3f27a1
--- /dev/null
+++ b/compat/time32/mtx_timedlock_base_time32.c
@@ -0,0 +1,9 @@
+#include "time32.h"
+#include <time.h>
+#include <threads.h>
+
+int __mtx_timedlock_base_time32(mtx_t *restrict m, int time_base, const struct timespec32 *restrict ts32)
+{
+	return mtx_timedlock_base(m, time_base, !ts32 ? 0 : (&(struct timespec){
+		.tv_sec = ts32->tv_sec, .tv_nsec = ts32->tv_nsec}));
+}
diff --git a/compat/time32/time32.h b/compat/time32/time32.h
index 1267f255..45ee6205 100644
--- a/compat/time32/time32.h
+++ b/compat/time32/time32.h
@@ -34,6 +34,7 @@ int __clock_gettime32() __asm__("clock_gettime");
 int __clock_nanosleep_time32() __asm__("clock_nanosleep");
 int __clock_settime32() __asm__("clock_settime");
 int __cnd_timedwait_time32() __asm__("cnd_timedwait");
+int __cnd_timedwait_base_time32() __asm__("cnd_timedwait_base");
 char *__ctime32() __asm__("ctime");
 char *__ctime32_r() __asm__("ctime_r");
 double __difftime32() __asm__("difftime");
@@ -56,6 +57,7 @@ time32_t __mktime32() __asm__("mktime");
 ssize_t __mq_timedreceive_time32() __asm__("mq_timedreceive");
 int __mq_timedsend_time32() __asm__("mq_timedsend");
 int __mtx_timedlock_time32() __asm__("mtx_timedlock");
+int __mtx_timedlock_base_time32() __asm__("mtx_timedlock_base");
 int __nanosleep_time32() __asm__("nanosleep");
 int __ppoll_time32() __asm__("ppoll");
 int __pselect_time32() __asm__("pselect");
diff --git a/include/threads.h b/include/threads.h
index 52ec3100..2c5f24f8 100644
--- a/include/threads.h
+++ b/include/threads.h
@@ -62,6 +62,7 @@ void mtx_destroy(mtx_t *);
 
 int mtx_lock(mtx_t *);
 int mtx_timedlock(mtx_t *__restrict, const struct timespec *__restrict);
+int mtx_timedlock_base(mtx_t *__restrict, int, const struct timespec *__restrict);
 int mtx_trylock(mtx_t *);
 int mtx_unlock(mtx_t *);
 
@@ -72,6 +73,7 @@ int cnd_broadcast(cnd_t *);
 int cnd_signal(cnd_t *);
 
 int cnd_timedwait(cnd_t *__restrict, mtx_t *__restrict, const struct timespec *__restrict);
+int cnd_timedwait_base(cnd_t *__restrict, mtx_t *__restrict, int, const struct timespec *__restrict);
 int cnd_wait(cnd_t *, mtx_t *);
 
 int tss_create(tss_t *, tss_dtor_t);
@@ -83,7 +85,9 @@ void *tss_get(tss_t);
 #if _REDIR_TIME64
 __REDIR(thrd_sleep, __thrd_sleep_time64);
 __REDIR(mtx_timedlock, __mtx_timedlock_time64);
+__REDIR(mtx_timedlock_base, __mtx_timedlock_base_time64);
 __REDIR(cnd_timedwait, __cnd_timedwait_time64);
+__REDIR(cnd_timedwait_base, __cnd_timedwait_base_time64);
 #endif
 
 #ifdef __cplusplus
diff --git a/src/thread/cnd_timedwait.c b/src/thread/cnd_timedwait.c
index 2802af52..60839fa0 100644
--- a/src/thread/cnd_timedwait.c
+++ b/src/thread/cnd_timedwait.c
@@ -4,11 +4,5 @@
 
 int cnd_timedwait(cnd_t *restrict c, mtx_t *restrict m, const struct timespec *restrict ts)
 {
-	int ret = __pthread_cond_timedwait((pthread_cond_t *)c, (pthread_mutex_t *)m, ts);
-	switch (ret) {
-	/* May also return EINVAL or EPERM. */
-	default:        return thrd_error;
-	case 0:         return thrd_success;
-	case ETIMEDOUT: return thrd_timedout;
-	}
+	return cnd_timedwait_base(c, m, TIME_UTC, ts);
 }
diff --git a/src/thread/cnd_timedwait_base.c b/src/thread/cnd_timedwait_base.c
new file mode 100644
index 00000000..b0b37cac
--- /dev/null
+++ b/src/thread/cnd_timedwait_base.c
@@ -0,0 +1,26 @@
+#include <threads.h>
+#include <pthread.h>
+#include <errno.h>
+
+int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int time_base, const struct timespec *restrict ts)
+{
+	clockid_t clock = CLOCK_REALTIME;
+	switch (time_base)
+	{
+	case TIME_UTC:
+		clock = CLOCK_REALTIME;
+		break;
+	case TIME_MONOTONIC:
+		clock = CLOCK_MONOTONIC;
+		break;
+	default:
+		return thrd_error;
+	}
+	int ret = pthread_cond_clockwait((pthread_cond_t *)c, (pthread_mutex_t *)m, clock, ts);
+	switch (ret) {
+	/* May also return EINVAL or EPERM. */
+	default:        return thrd_error;
+	case 0:         return thrd_success;
+	case ETIMEDOUT: return thrd_timedout;
+	}
+}
diff --git a/src/thread/mtx_timedlock.c b/src/thread/mtx_timedlock.c
index d22c8cf4..49a28623 100644
--- a/src/thread/mtx_timedlock.c
+++ b/src/thread/mtx_timedlock.c
@@ -4,10 +4,5 @@
 
 int mtx_timedlock(mtx_t *restrict m, const struct timespec *restrict ts)
 {
-	int ret = __pthread_mutex_timedlock((pthread_mutex_t *)m, ts);
-	switch (ret) {
-	default:        return thrd_error;
-	case 0:         return thrd_success;
-	case ETIMEDOUT: return thrd_timedout;
-	}
+	return mtx_timedlock_base(m, TIME_UTC, ts);
 }
diff --git a/src/thread/mtx_timedlock_base.c b/src/thread/mtx_timedlock_base.c
new file mode 100644
index 00000000..3dda19ab
--- /dev/null
+++ b/src/thread/mtx_timedlock_base.c
@@ -0,0 +1,25 @@
+#include <threads.h>
+#include <pthread.h>
+#include <errno.h>
+
+int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct timespec *restrict ts)
+{
+	clockid_t clock = CLOCK_REALTIME;
+	switch (time_base)
+	{
+	case TIME_UTC:
+		clock = CLOCK_REALTIME;
+		break;
+	case TIME_MONOTONIC:
+		clock = CLOCK_MONOTONIC;
+		break;
+	default:
+		return thrd_error;
+	}
+	int ret = pthread_mutex_clocklock((pthread_mutex_t *)m, clock, ts);
+	switch (ret) {
+	default:        return thrd_error;
+	case 0:         return thrd_success;
+	case ETIMEDOUT: return thrd_timedout;
+	}
+}
-- 
2.39.0.windows.1

Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[Rich Felker]

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

Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]

On Wed, Jun 21, 2023 at 6:47 AM 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, 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


> 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.

> 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:

how to do that?

>
> - 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



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[-- Attachment #2: Type: text/html, Size: 4496 bytes --]

Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[Rich Felker]

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@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, 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

Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 3944 bytes --]

On Wed, Jun 21, 2023 at 10:54 PM Rich Felker <dalias@libc.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@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, 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

[-- Attachment #2: Type: text/html, Size: 4896 bytes --]

Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[enh]

[-- Attachment #1: Type: text/plain, Size: 4361 bytes --]

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@gmail.com>
wrote:

>
>
> On Wed, Jun 21, 2023 at 10:54 PM Rich Felker <dalias@libc.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@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, 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
>

[-- Attachment #2: Type: text/html, Size: 5515 bytes --]

Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 4105 bytes --]

On Wed, Jun 21, 2023 at 6:47 AM 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, 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:

LKML-style patches are generally used, what makes musl should not use that?
If email is the only way to submit patches for musl, I think LKML-style
patches have general agreement,
otherwise it's better to use github/gitlab to do that.
Because the LKML-style patches can be sent by using `git git-send-email` to
do that.
So the following reasons is not a issue for glibc/linux/qemu and so on,
they have much larger volume.

>
> - 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



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[-- Attachment #2: Type: text/html, Size: 4747 bytes --]

Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base

[Rich Felker]

On Wed, Jun 21, 2023 at 02:25:58PM +0800, 罗勇刚(Yonggang Luo) wrote:
> On Wed, Jun 21, 2023 at 6:47 AM Rich Felker <dalias@libc.org> wrote:
> > 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:
> 
> LKML-style patches are generally used, what makes musl should not use that?
> If email is the only way to submit patches for musl, I think LKML-style
> patches have general agreement,
> otherwise it's better to use github/gitlab to do that.
> Because the LKML-style patches can be sent by using `git git-send-email` to
> do that.
> So the following reasons is not a issue for glibc/linux/qemu and so on,
> they have much larger volume.

It's not the way we do things here, and I explained why. git has an
equally easy (arguably easier since it doesn't require the git command
to invoke your mail tools) way to do patches as attachments.

    git format-patch -4

will produce files 0001-...patch, 0002-...patch, 0003-...patch,
0004-...patch for the last 4 commits (replace 4 with whatever number
you need) which can then be attached via whatever method you normally
use in your mail software.

Rich