gh-112606: Use sem_clockwait with monotonic time when supported in parking_lot.c

[mattprodani]

Completes one part of moving parking_lot.c's semaphore waiting to prefer functions that support CLOCK_MONOTONIC Uses sem_clockwait in the semaphore-based implementation. Split with previous PR to move support for CLOCK_MONOTONIC in pthread_condvar_t implementation to a separate PR.

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

[colesbury]

Thanks, this looks good to me. @corona10 can you review this please?

[colesbury]

Also cc @vstinner - CLOCK_MONOTONIC fixes in parking_lot.c

[vstinner]

I wrote similar code in Python/thread_pthread.h. Here is my review.

---

This change only fix one code path. The code path if _Py_USE_SEMAPHORES is not defined still uses the system clock. pthread_condattr_setclock(&ca, CLOCK_MONOTONIC) can be used for that: see Python/thread_pthread.h.

---

Unrelated to this PR, I have concerns about _PySemaphore_PlatformWait().

(DWORD) (timeout / 1000000) can overflow in the Windows code path. Using _PyTime_As100Nanoseconds() may be a good start.

PEP 475 "Retry system calls failing with EINTR" is not supported: the caller has to handle Py_PARK_INTR. The problem is that it's quite hard to recompute properly a timeout to take in account time elapsed by the call which failed with Py_PARK_INTR. It would be better to retry on EINTR and recompute the timeout. Similar to what Python/thread_pthread.h does in PyThread_acquire_lock_timed(). For the sem_clockwait() code path, it's easy, since we only have to compute an absolute timestamp once.

[mattprodani]

@vstinner Thanks for reviewing, I'm finishing up the remaining pthread_cond_t path similarly to thread_pthread.h but we decided to split it into a different PR. I'll update with the documentation changes.

[corona10]

I will take look this PR today

[colesbury]

@vstinner Please see the other PR, which is still a draft, for discussion about the pthreads code path: #112616. I don't think condattr_monotonic helps here because only macOS uses the pthreads code path in parking_lot.c and it doesn't support pthread_condattr_setclock. But we can use the macOS extension pthread_cond_timedwait_relative_np to avoid timezone issues.

(DWORD) (timeout / 1000000) - thanks, filed #112804

"Retry system calls failing with EINTR" - Interrupts are properly retried. It happens at a higher level in the abstraction, see _PyMutex_LockTimed. The timeout computation there copies the pattern from thread_pthread.h.