gh-112606: Use pthread_cond_timedwait_relative_np in parking_lot.c when available

[mattprodani]

Updates parking_lot.c to prefer functions that support CLOCK_MONOTONIC for semaphore and pthread_cond_t based implementations of _PySemaphore_PlatformWait.

Updated: to instead use pthread_cond_timedwait_relative_np with a relative timeout which is supported on MacOS, unlike pthread_condattr_setclock(..., CLOCK_MONOTONIC). Part of work to make parking_lot.c timing more accurate.

Linked to PR for POSIX semaphores.

• Issue: parking_lot.c should use _PyTime_GetMonotonicClock() when available #112606

[colesbury]

The semaphore bits look good. The pthread_cond_timedwait parts need some work and might be a bit tricky. If you like, you can split it into two PRs, or keep as one if you prefer.

[mattprodani]

The semaphore bits look good. The pthread_cond_timedwait parts need some work and might be a bit tricky. If you like, you can split it into two PRs, or keep as one if you prefer.

@colesbury Thanks for reviewing. I think I'll go ahead and split the PR here and work on the condvar initialization part.

[mattprodani]

Updated parking lot.c PR: @vstinner @colesbury - use macOS relative clock specific pthread_cond_timedwait_relative_np as discussed.

[vstinner]

I would feel more comfortable if Python/thread_pthread.h and Python/parking_lot.c would use the same implementation (more or less). So I would suggest to start first with pthread_condattr_setclock() to support most Unix.

Then, if macOS doesn't support pthread_condattr_setclock(), I would also like to see Python/thread_pthread.h being modified to use it.

[mattprodani]

@vstinner , likely @colesbury can be more useful about what I am saying, but to me, for the common unix implementation, that should have been dealt with on #112733 which uses sem_clockwait on plain semaphores as a base rather than a pthread condvar/mutex pair. (as available). The remaining branch that uses a condition variable and a mutex seems to mainly target macOS, which does not support pthread_condattr_setclock or sem_clockwait.

[colesbury]

@vstinner, pthread_condattr_setclock would just be dead code in parking_lot.c. All the other Unixes use the semaphore code path (Linux, FreeBSD, AIX, etc.). Additionally, it's a bit tricky to do the attribute initialization once in a thread-safe manner.

I agree that it would be better to use the same implementation. In this case, that probably means more use of the condvar.h file. (thread_pthread.h is not suitable for re-use -- it can only be included once in thread.c). That still requires a bit of a refactor due to the use of microseconds vs. nanoseconds, so I'd prefer to fix the immediate issue and then follow up with the refactoring.

[erlend-aasland]

@mattprodani, can you resolve the conflicts and address the latest round of comments?

[mattprodani]

@mattprodani, can you resolve the conflicts and address the latest round of comments?

Autoconf merge conflict is resolved.

It looks like, now, the only case where we could share condition variable implementation between thread_pthread.h and parking_lot.c is on Mac. Unless we want to work on refactoring condvar.h now, the PR should be complete as it fixes the immediate issue as discussed by @colesbury's last comment.

[erlend-aasland]

Configure changes LGTM. I'll leave parking lot for Sam :)

[colesbury]

This LGTM too.

As Victor pointed out, there similar logic in Python/thread_pthread.h, but I think that refactoring out the common logic is a bit complicated and better left to a subsequent change.

[erlend-aasland]

@mattprodani, can you fix the merge conflicts?

[mattprodani]

@mattprodani, can you fix the merge conflicts?

Done, there was a new change to configure. Decided to rebase here but parking_lot.c remains unchanged from last review.

[erlend-aasland]

Done, there was a new change to configure. Decided to rebase here but parking_lot.c remains unchanged from last review.

Thanks; note that we prefer git merge --no-ff main to rebase and force-push; it plays better with the GitHub UI. See also the devguide.

[erlend-aasland]

As Victor pointed out, there similar logic in Python/thread_pthread.h, but I think that refactoring out the common logic is a bit complicated and better left to a subsequent change.

Next, refactoring? :)