c23 is already released, is there any plan about add monotonic mtx_t and cnd_t in next revision of c standard? I would suggest add the following two extra function to achieve monotonic mtx and cnd support
int mtx_monotonic_init(mtx_t *__mtx, int type); int cnd_monotonic_init(cnd_t *__cnd); On Mon, Mar 21, 2022 at 10:36 PM Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > > > > From: austin-group-l@opengroup.org <austin-group-l@opengroup.org> > Sent: Sunday, March 20, 2022 6:45 AM > To: Jₑₙₛ Gustedt <jens.gust...@inria.fr> > Cc: David Keaton <d...@dmk.com>; austin-group-l@opengroup.org > Subject: Re: cnd_timedwait and mtx_timedlock may leading to deadlock. > > > > > > On Sun, Mar 20, 2022 at 4:58 PM Jₑₙₛ Gustedt <jens.gust...@inria.fr> wrote: > > > > Hello > > > > On Sat, 19 Mar 2022 18:07:20 +0800, 罗勇刚(Yonggang Luo) wrote: > > > > > On Thu, Mar 17, 2022 at 5:37 PM Jₑₙₛ Gustedt <jens.gust...@inria.fr> > > > wrote: > > > > > > Second, C's condition variable interface is choosen to be much, much > > > > simpler that POSIX'. In particular (other than for mutexes, for > > > > example) we don't have any additional parameter to the intialization > > > > of a condition variable that would allow to parametrize for example > > > > the associated clock. > > > > > > How about this : > > > ```c > > > // default to TIME_UTC, if failed(such as not supported), return -1 > > > int cnd_set_timedbase(int base); > > > int mtx_set_timedbase(int base); > > > ``` > > > > That would globally set a time base for all mutexes or condition > > variable? So this would change a global state? Would these functions > > be thread safe? How would you expect to coordinate between different > > libraries that are linked together in one executable and that might > > have different expectations? > > > > This doesn't sound like a design that I personnally would support. > > > > > > Third, WG14 only standardizes existing practice and here this would > > > > be a particular burden for non-POSIX implementations of C threads. > > > > They might not have enough room for internal state of each condition > > > > variable to reflect a change in the clock, for example. > > > ``` > > > On windows, that's can be implemented, > > > ``` > > > > "Can be implemented" is not the same as has been implemented and is > > deployed and used by applications. > > > > > > Fourth, we are already in feature freeze for C23, so such a change > > > > would only go in a future version of C (whenever that may be). > > > > > That's acceptable > > > > But still I have real difficulties in seeing the usefulness of all of > > this. For me the goal seems to be to provide interfaces that permit to > > code around implementations with low quality. If I would be motivated > > to work in such a direction (and I clearly am not) I think it would be > > much more promissing to relax the requirement for these interfaces to > > use `TIME_UTC` and replace it by `TIME_MONOTONIC` (and no other > > calendars) if possible. This could be done by providing a macro > > `THRD_USED_TIME` or so that would resolve to the time that is used, > > and then applications that have `TIME_MONOTONIC` could move towards > > using this instead of `TIME_UTC`. > > > > Execellent, this is very good for me. Can this be added to > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2647.pdf? > > > > Indeed, the only threads.h implementation I know is musl(maybe there is others) > > > > FreeBSD has one. That implementation is also used by RTEMS. > > > > > > The only important thing here would be to have these functions use a > > calendar that has better properties than `TIME_UTC`. I don't see much > > gain in providing a user-controlled knob that complicates both sides, > > implementation and applications, without providing a real semantic > > improvement. > > > > Unless added in recent years, the lack of being able to specific priority, scheduling parameters, and stack size is a big deficiency. > > > > We (RTEMS and safety group I am on) see C/C++ threads as convenient for code being ported but should never be used for a critical embedded system because their execution characteristics are not robust enough. > > > > --joel > > RTEMS > > > > > > Thanks > > Jₑₙₛ > > > > > > -- > > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > > :: ::::::::::::::: office Strasbourg : +33 368854536 :: > > :: :::::::::::::::::::::: gsm France : +33 651400183 :: > > :: ::::::::::::::: gsm international : +49 15737185122 :: > > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > > > > -- > 此致 > 礼 > 罗勇刚 > Yours > sincerely, > Yonggang Luo -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
