Mutex initialization and destruction duration does not depend on the number of mutex in use in the system -- for any type of mutex. Mutex initialization then destruction does not consume any system resource (memory leak, ...) -- for any type of mutex. With a large amount of threads contending for some mutexes (of several types) with pthread_mutex_lock, pthread_mutex_trylock and pthread_mutex_timedlock, there is never more than one thread owning the same mutex at the same time. There is no limit on the number of threads waiting to own the same mutex. There is no limit on the number of different mutex having threads contending, at the same time. Condvar initialization then destruction does not consume any system resource -- for any kind of condvar. Condvar Initialization and destruction duration does not depend on the number of condvars in use in the system -- for any kind of condvar. Latency between pthread_cond_timedwait timeout parameter and function actual return does not depend on the number of threads waiting on the condvar -- whatever kind of condvar. When inside the function, the thread releases the mutex before waiting for the conditionnal variable. Those two operations are atomic in the mean that no other thread can gain access to the mutex then signal (or broadcast) the condition without the blocked thread behaving as if this signal (or broadcast) had happened after it blocked on the conditionnal variable. When a cancel request unblocks the thread, it must not consume any pending condition signal request. No condition signaling (signal or broadcast) are lost (i.e. not received by at least one (wait) or all (broadcast) waiting threads). The thread creation time does not depend on the number of threads already created in the process. pthread_mutex_trylock never locks the mutex when it returns EBUSY. pthread_exit() frees the thread resources. pthread_self() returns the thread ID. The process creation time in a fork() does not depend on the number of processes already created in the system. The init_routine argument of pthread_once is never called more or less than once. pthread_getschedparam() always returns the scheduling parameters of the queried thread. Heavy signal delivery with pthread_kill() does not break the system, and no unpending signal get lost. Heavy cancelation does not break the system or the application. The sem_open and sem_close duration does not depend on the number of opened named semaphores. The sem_init and sem_destroy duration does not depend on the number of opened unnamed semaphores. The sem_getvalue always returns the value of the semaphore at a given time during the call into the sval argument.