On Fri, Mar 13, 2020 at 6:53 PM Gregory Nutt <spudan...@gmail.com> wrote:
> Nathan, > > There is one issue we have to be careful about: pthread > _mutex_timedlock(): It needs the signal in order to wake up and return > from the wait. pthread_mutex_lock() just calls pthread_mutex_timedlock() > with and time value of NULL. So it is this NULL argument that is passed > must cause different behaviors: Non-NULL: interruptible and NULL: > noninterruptible. > > Now, the subtle questions: > > - Should the behavior of pthread_mutex_timelock() be the same as > pthread_mutex_lock() if the timeout is NULL? I don't see any discussion > of this at OpenGroup.org. My guess is yes. I have been trying to figure out the answer to this question. I am guessing that yes, because this page [1] says: "The pthread_mutex_timedlock() function shall lock the mutex object referenced by mutex. If the mutex is already locked, the calling thread shall block until the mutex becomes available as in the pthread_mutex_lock() function." I **think** "shall block...as in the pthread_mutex_lock()" means that, yes, because that function's description includes: "If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread shall resume waiting for the mutex as if it was not interrupted." - The timed wait will be awakened with a particular signal, but it could > also be awakened if an unrelated signal is received. Should there be a > signprocmask() to block other signals while waiting? I don't know. This will require more digging. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_timedlock.html Nathan
