[v2,0/4] c2y proposal add monotonicwait support for mtx and ctx

Message ID 20230620171731.230-1-luoyonggang@gmail.com
Headers
Series c2y proposal add monotonicwait support for mtx and ctx |

Message

Yonggang Luo June 20, 2023, 5:17 p.m. UTC
  For c11 threads, the mtx and cnd doesn't support for monotonic timedlock and timedwait;
So add two proposal 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.

Yonggang Luo (4):
  clang-format: should format with 2 space and do not usage tab
  time: Implement c23 timespec_get base
  c11: Switch to use pthread_mutex_clocklock and pthread_cond_clockwait
    to implement cnd and mtx lock and wait
  c2y: Add function cnd_timedwait_base and mtx_timedlock_base

 .clang-format                                 |   4 +-
 conform/data/threads.h-data                   |   2 +
 htl/Versions                                  |   5 +
 nptl/Versions                                 |   5 +
 sysdeps/pthread/Makefile                      |   2 +
 sysdeps/pthread/cnd_timedwait.c               |   8 +-
 .../{cnd_timedwait.c => cnd_timedwait_base.c} |  58 +++++-----
 sysdeps/pthread/mtx_timedlock.c               |   6 +-
 .../{mtx_timedlock.c => mtx_timedlock_base.c} |  56 +++++-----
 sysdeps/pthread/threads.h                     |  18 ++++
 sysdeps/unix/sysv/linux/Versions              |   6 ++
 sysdeps/unix/sysv/linux/cnd_timedwait.c       |   4 +-
 .../{cnd_timedwait.c => cnd_timedwait_base.c} |  24 +++--
 sysdeps/unix/sysv/linux/mtx_timedlock.c       |   4 +-
 .../{mtx_timedlock.c => mtx_timedlock_base.c} | 100 +++++++++---------
 sysdeps/unix/sysv/linux/thrd_priv.h           |  10 ++
 time/time.h                                   |  13 ++-
 time/timespec_get.c                           |  51 ++++++++-
 18 files changed, 240 insertions(+), 136 deletions(-)
 copy sysdeps/pthread/{cnd_timedwait.c => cnd_timedwait_base.c} (70%)
 copy sysdeps/pthread/{mtx_timedlock.c => mtx_timedlock_base.c} (75%)
 copy sysdeps/unix/sysv/linux/{cnd_timedwait.c => cnd_timedwait_base.c} (60%)
 copy sysdeps/unix/sysv/linux/{mtx_timedlock.c => mtx_timedlock_base.c} (60%)
  

Comments

Joseph Myers June 20, 2023, 8:45 p.m. UTC | #1
I think it's a misrepresentation to refer to this as a C2y proposal.  
You're proposing a new GNU interface and should describe it as such and 
justify it as such.  Maybe you intend to propose it for C2y or C3x 
(whatever the next C standard revision is - we haven't decided on a 
schedule and that's not up for discussion again before the October meeting 
at the earliest), but I don't see a WG14 document with such a proposal, 
and proposals for the next C standard revision can't now be taken until 
the C2x ballots (DIS, possibly FDIS) have completed, some time in 2024.
  
develop--- via Libc-alpha June 21, 2023, 6:52 a.m. UTC | #2
On Wed, Jun 21, 2023 at 4:45 AM Joseph Myers <joseph@codesourcery.com>
wrote:
>
> I think it's a misrepresentation to refer to this as a C2y proposal.
> You're proposing a new GNU interface and should describe it as such and
> justify it as such.  Maybe you intend to propose it for C2y or C3x
> (whatever the next C standard revision is - we haven't decided on a
> schedule and that's not up for discussion again before the October meeting
> at the earliest), but I don't see a WG14 document with such a proposal,

This is a prepare for such a proposal, I asked  Jens Gustedt before about
such a  proposal, He suggest me
try do the implementation in libc first, And that's make sense, and it's
make me found the properly function prototype
for this. It's doesn't need to be merged as soon as possible, but give us
an indication that the correct direction to achieve
monotonic mtx/cnd lock/wait support in C2y or C3x, And if that's direction
is correct, I would like to use it in project mesa first and waiting
the C2y or C3x to be appeared with such a proposal.


> and proposals for the next C standard revision can't now be taken until
> the C2x ballots (DIS, possibly FDIS) have completed, some time in 2024.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  
Xi Ruoyao June 21, 2023, 7:14 a.m. UTC | #3
On Wed, 2023-06-21 at 14:52 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha
wrote:
> It's doesn't need to be merged as soon as possible, but give us
> an indication that the correct direction to achieve
> monotonic mtx/cnd lock/wait support in C2y or C3x, And if that's direction
> is correct, I would like to use it in project mesa first and waiting
> the C2y or C3x to be appeared with such a proposal.

Then you should use [PATCH RFC] in the subject.  Without "RFC" it's
assumed the author consider the patch ready for git master.