Pthread cond timedwait which clock

Blocking, however, is irrelevant if an absolute timeout is used. An absolute timeout also need not be recomputed if it is used multiple times in a loop, such as that enclosing a condition wait. For cases when the system clock is advanced discontinuously by an operator, it is expected that implementations process any timed wait expiring at an intervening time as if that time had actually occurred.

A condition wait, whether timed or not, is a cancellation point. The reason for this is that an indefinite wait is possible at these points-whatever event is being waited for, even if the program is totally correct, might never occur; for example, some input data being awaited might never be sent. By making condition wait a cancellation point, the thread can be canceled and perform its cancellation cleanup handler even though it may be stuck in some indefinite wait. A side effect of acting on a cancellation request while a thread is blocked on a condition variable is to re-acquire the mutex before calling any of the cancellation cleanup handlers.

This is done in order to ensure that the cancellation cleanup handler is executed in the same state as the critical code that lies both before and after the call to the condition wait function.

Without this rule, there would not be a uniform rule that exception handlers could follow regarding the lock, and so coding would become very cumbersome. Therefore, since some statement has to be made regarding the state of the lock when a cancellation is delivered during a wait, a definition has been chosen that makes application coding most convenient and error free.

When acting on a cancellation request while a thread is blocked on a condition variable, the implementation is required to ensure that the thread does not consume any condition signals directed at that condition variable if there are any other threads waiting on that condition variable. This rule is specified in order to avoid deadlock conditions that could occur if these two independent requests one acting on a thread and the other acting on the condition variable were not processed independently.

Mutexes are expected to be locked only for a few instructions. The calling thread is blocked until either another thread performs a signal or broadcast on the condition variable, the absolute time specified by abstime has passed, a signal is delivered to the thread, or the thread is canceled waiting on a condition variable is a cancellation point.

In all cases, the thread reacquires the mutex before being unblocked. If the absolute time specified by abstime passes and the indicated condition has not been signaled, the function returns an error to the caller. Note: abstime is the time at which the wait expires, not the length of time the thread will wait.

Both functions should be called with mutex locked by the calling thread. If mutex is not locked by the calling thread, undefined behavior will result. These functions atomically release mutex and cause the calling thread to block on the condition variable cond.

When the condition is signaled or the timed wait expires, the caller is unblocked and will reacquire mutex before returning. Whether these functions succeed or fail, mutex will always be reacquired before returning to the caller. Using different mutexes for concurrent calls to these functions on the same condition variable results in undefined behavior.

When using condition variables, there is a predicate associated with the condition wait. If this predicate is false, the thread should perform a condition wait. See pthreads 5. A condition wait whether timed or not is a cancellation point.

The abstime argument is of type struct timespec , defined in time. The reltime argument is of type struct timespec , defined in time. An error value is returned if the relative time passes that is, system time equals or exceeds the starting system time plus the relative time before the condition cond is signaled or broadcast. If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread resumes waiting for the condition variable as if it was not interrupted, or it returns 0 due to spurious wakeup.