[musl] pthread_mutex_timedlock

[musl] pthread_mutex_timedlock

[Daniele GMail]

Hi,
I have a question about pthread_mutex_timedlock.

From the man page I see

[...]

If the Timers option is supported, the timeout shall be based on the
CLOCK_REALTIME clock; if the Timers option is not supported, the
timeout shall be based on the system clock as returned by the time()
function.

[...]

Can anybody explain me why there's no possibility to choose a different
clock like could be done for the pthread_cond_timedwait?

I have a lot of places in my code where timedlock of mutexes affected
by time changes could lead to problems and it is really difficult to
distinguish timeouts caused by time changes from other ones in order to
decide how to react.

Can someone point me to a portable workaround for this?

Thanks in advance,
Daniele.

Re: [musl] pthread_mutex_timedlock

[Samuel Holland]

On 10/4/24 08:02, Daniele GMail wrote:
> Hi,
> I have a question about pthread_mutex_timedlock.
> 
> From the man page I see
> 
> [...]
> 
> If the Timers option is supported, the timeout shall be based on the
> CLOCK_REALTIME clock; if the Timers option is not supported, the
> timeout shall be based on the system clock as returned by the time()
> function.
> 
> [...]
> 
> Can anybody explain me why there's no possibility to choose a different
> clock like could be done for the pthread_cond_timedwait?

This is an omission in the standard[0], that was resolved in POSIX
2024[1] by adding pthread_mutex_clocklock(), which does what you want.

[0]: https://www.austingroupbugs.net/view.php?id=1216
[1]:
https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/pthread_mutex_clocklock.html

> I have a lot of places in my code where timedlock of mutexes affected
> by time changes could lead to problems and it is really difficult to
> distinguish timeouts caused by time changes from other ones in order to
> decide how to react.
> 
> Can someone point me to a portable workaround for this?
> 
> Thanks in advance,
> Daniele.

Re: [musl] pthread_mutex_timedlock

[Daniele GMail]

On Fri, 2024-10-04 at 09:16 -0500, Samuel Holland wrote:
> On 10/4/24 08:02, Daniele GMail wrote:
> > Hi,
> > I have a question about pthread_mutex_timedlock.
> > 
> > From the man page I see
> > 
> > [...]
> > 
> > If the Timers option is supported, the timeout shall be based on
> > the
> > CLOCK_REALTIME clock; if the Timers option is not supported, the
> > timeout shall be based on the system clock as returned by the
> > time()
> > function.
> > 
> > [...]
> > 
> > Can anybody explain me why there's no possibility to choose a
> > different
> > clock like could be done for the pthread_cond_timedwait?
> 
> This is an omission in the standard[0], that was resolved in POSIX
> 2024[1] by adding pthread_mutex_clocklock(), which does what you
> want.
> 
> [0]: https://www.austingroupbugs.net/view.php?id=1216
> [1]:
> https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/pthread_mutex_clocklock.html

Oh, this is great news.

But guess that since this is dated 2024 is not yet part of musl 1.2.5
right? Are there plans on when it will be available?

> 
> > I have a lot of places in my code where timedlock of mutexes
> > affected
> > by time changes could lead to problems and it is really difficult
> > to
> > distinguish timeouts caused by time changes from other ones in
> > order to
> > decide how to react.
> > 
> > Can someone point me to a portable workaround for this?
> > 
> > Thanks in advance,
> > Daniele.

Re: [musl] pthread_mutex_timedlock

[zxuiji]

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

Since he brought up the function it's likely already in musl

On Fri, 4 Oct 2024 at 16:11, Daniele GMail <d.dario76@gmail.com> wrote:

> On Fri, 2024-10-04 at 09:16 -0500, Samuel Holland wrote:
> > On 10/4/24 08:02, Daniele GMail wrote:
> > > Hi,
> > > I have a question about pthread_mutex_timedlock.
> > >
> > > From the man page I see
> > >
> > > [...]
> > >
> > > If the Timers option is supported, the timeout shall be based on
> > > the
> > > CLOCK_REALTIME clock; if the Timers option is not supported, the
> > > timeout shall be based on the system clock as returned by the
> > > time()
> > > function.
> > >
> > > [...]
> > >
> > > Can anybody explain me why there's no possibility to choose a
> > > different
> > > clock like could be done for the pthread_cond_timedwait?
> >
> > This is an omission in the standard[0], that was resolved in POSIX
> > 2024[1] by adding pthread_mutex_clocklock(), which does what you
> > want.
> >
> > [0]: https://www.austingroupbugs.net/view.php?id=1216
> > [1]:
> >
> https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/pthread_mutex_clocklock.html
>
> Oh, this is great news.
>
> But guess that since this is dated 2024 is not yet part of musl 1.2.5
> right? Are there plans on when it will be available?
>
> >
> > > I have a lot of places in my code where timedlock of mutexes
> > > affected
> > > by time changes could lead to problems and it is really difficult
> > > to
> > > distinguish timeouts caused by time changes from other ones in
> > > order to
> > > decide how to react.
> > >
> > > Can someone point me to a portable workaround for this?
> > >
> > > Thanks in advance,
> > > Daniele.
>
>

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

Re: [musl] pthread_mutex_timedlock

[Daniele GMail]

On Sat, 2024-10-05 at 05:18 +0100, zxuiji wrote:
> Since he brought up the function it's likely already in musl
> 
> On Fri, 4 Oct 2024 at 16:11, Daniele GMail <d.dario76@gmail.com>
> wrote:
> > On Fri, 2024-10-04 at 09:16 -0500, Samuel Holland wrote:
> > > On 10/4/24 08:02, Daniele GMail wrote:
> > > > Hi,
> > > > I have a question about pthread_mutex_timedlock.
> > > > 
> > > > From the man page I see
> > > > 
> > > > [...]
> > > > 
> > > > If the Timers option is supported, the timeout shall be based
> > > > on
> > > > the
> > > > CLOCK_REALTIME clock; if the Timers option is not supported,
> > > > the
> > > > timeout shall be based on the system clock as returned by the
> > > > time()
> > > > function.
> > > > 
> > > > [...]
> > > > 
> > > > Can anybody explain me why there's no possibility to choose a
> > > > different
> > > > clock like could be done for the pthread_cond_timedwait?
> > > 
> > > This is an omission in the standard[0], that was resolved in
> > > POSIX
> > > 2024[1] by adding pthread_mutex_clocklock(), which does what you
> > > want.
> > > 
> > > [0]: https://www.austingroupbugs.net/view.php?id=1216
> > > [1]:
> > > https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/pthread_mutex_clocklock.html
> > 
> > Oh, this is great news.
> > 
> > But guess that since this is dated 2024 is not yet part of musl
> > 1.2.5
> > right? Are there plans on when it will be available?
> > 
> > > 
> > > > I have a lot of places in my code where timedlock of mutexes
> > > > affected
> > > > by time changes could lead to problems and it is really
> > > > difficult
> > > > to
> > > > distinguish timeouts caused by time changes from other ones in
> > > > order to
> > > > decide how to react.
> > > > 
> > > > Can someone point me to a portable workaround for this?
> > > > 
> > > > Thanks in advance,
> > > > Daniele.
> > 

I might be wrong but I don't see it in master tree: am I missing
something?

Re: [musl] pthread_mutex_timedlock

[zxuiji]

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

Maybe it's implemented but in a separate branch because it's not yet
official

On Mon, 7 Oct 2024 at 09:11, Daniele GMail <d.dario76@gmail.com> wrote:

> On Sat, 2024-10-05 at 05:18 +0100, zxuiji wrote:
> > Since he brought up the function it's likely already in musl
> >
> > On Fri, 4 Oct 2024 at 16:11, Daniele GMail <d.dario76@gmail.com>
> > wrote:
> > > On Fri, 2024-10-04 at 09:16 -0500, Samuel Holland wrote:
> > > > On 10/4/24 08:02, Daniele GMail wrote:
> > > > > Hi,
> > > > > I have a question about pthread_mutex_timedlock.
> > > > >
> > > > > From the man page I see
> > > > >
> > > > > [...]
> > > > >
> > > > > If the Timers option is supported, the timeout shall be based
> > > > > on
> > > > > the
> > > > > CLOCK_REALTIME clock; if the Timers option is not supported,
> > > > > the
> > > > > timeout shall be based on the system clock as returned by the
> > > > > time()
> > > > > function.
> > > > >
> > > > > [...]
> > > > >
> > > > > Can anybody explain me why there's no possibility to choose a
> > > > > different
> > > > > clock like could be done for the pthread_cond_timedwait?
> > > >
> > > > This is an omission in the standard[0], that was resolved in
> > > > POSIX
> > > > 2024[1] by adding pthread_mutex_clocklock(), which does what you
> > > > want.
> > > >
> > > > [0]: https://www.austingroupbugs.net/view.php?id=1216
> > > > [1]:
> > > >
> https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/pthread_mutex_clocklock.html
> > >
> > > Oh, this is great news.
> > >
> > > But guess that since this is dated 2024 is not yet part of musl
> > > 1.2.5
> > > right? Are there plans on when it will be available?
> > >
> > > >
> > > > > I have a lot of places in my code where timedlock of mutexes
> > > > > affected
> > > > > by time changes could lead to problems and it is really
> > > > > difficult
> > > > > to
> > > > > distinguish timeouts caused by time changes from other ones in
> > > > > order to
> > > > > decide how to react.
> > > > >
> > > > > Can someone point me to a portable workaround for this?
> > > > >
> > > > > Thanks in advance,
> > > > > Daniele.
> > >
>
> I might be wrong but I don't see it in master tree: am I missing
> something?
>

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

Re: [musl] pthread_mutex_timedlock

[Rich Felker]

On Mon, Oct 07, 2024 at 08:44:30PM +0100, zxuiji wrote:
> Maybe it's implemented but in a separate branch because it's not yet
> official

Could you stick to providing information you can verify when trying to
help folks on the list rather than just speculating? The clocklock
functions, along with various other functionality in the recently
published POSIX and C revisions, are not yet implemented. They should
be added sometime soon though.

FWIW, the kinds of errors that can be hit from clock changing are
non-issues if you have NTP configured to only make skew adjustments
rather than jumping the clock.

> On Mon, 7 Oct 2024 at 09:11, Daniele GMail <d.dario76@gmail.com> wrote:
> 
> > On Sat, 2024-10-05 at 05:18 +0100, zxuiji wrote:
> > > Since he brought up the function it's likely already in musl
> > >
> > > On Fri, 4 Oct 2024 at 16:11, Daniele GMail <d.dario76@gmail.com>
> > > wrote:
> > > > On Fri, 2024-10-04 at 09:16 -0500, Samuel Holland wrote:
> > > > > On 10/4/24 08:02, Daniele GMail wrote:
> > > > > > Hi,
> > > > > > I have a question about pthread_mutex_timedlock.
> > > > > >
> > > > > > From the man page I see
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > If the Timers option is supported, the timeout shall be based
> > > > > > on
> > > > > > the
> > > > > > CLOCK_REALTIME clock; if the Timers option is not supported,
> > > > > > the
> > > > > > timeout shall be based on the system clock as returned by the
> > > > > > time()
> > > > > > function.
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > Can anybody explain me why there's no possibility to choose a
> > > > > > different
> > > > > > clock like could be done for the pthread_cond_timedwait?
> > > > >
> > > > > This is an omission in the standard[0], that was resolved in
> > > > > POSIX
> > > > > 2024[1] by adding pthread_mutex_clocklock(), which does what you
> > > > > want.
> > > > >
> > > > > [0]: https://www.austingroupbugs.net/view.php?id=1216
> > > > > [1]:
> > > > >
> > https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/pthread_mutex_clocklock.html
> > > >
> > > > Oh, this is great news.
> > > >
> > > > But guess that since this is dated 2024 is not yet part of musl
> > > > 1.2.5
> > > > right? Are there plans on when it will be available?
> > > >
> > > > >
> > > > > > I have a lot of places in my code where timedlock of mutexes
> > > > > > affected
> > > > > > by time changes could lead to problems and it is really
> > > > > > difficult
> > > > > > to
> > > > > > distinguish timeouts caused by time changes from other ones in
> > > > > > order to
> > > > > > decide how to react.
> > > > > >
> > > > > > Can someone point me to a portable workaround for this?
> > > > > >
> > > > > > Thanks in advance,
> > > > > > Daniele.
> > > >
> >
> > I might be wrong but I don't see it in master tree: am I missing
> > something?
> >