1<assertions> 2 <assertion id="1" files="pthread_mutex_init/stress.c" tag="pt:THR"> 3Mutex initialization and destruction duration does not depend on the number of mutex in use in the system -- for any type of mutex. 4 </assertion> 5 <assertion id="2" files="pthread_mutex_init/s-c.c" tag="pt:THR"> 6Mutex initialization then destruction does not consume any system resource (memory leak, ...) -- for any type of mutex. 7 </assertion> 8 <assertion id="3" files="pthread_mutex_lock/stress.c" tag="pt:THR"> 9With 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. 10 </assertion> 11 <assertion id="4" files="pthread_mutex_lock/s-c1.c" tag="pt:THR"> 12There is no limit on the number of threads waiting to own the same mutex. 13 </assertion> 14 <assertion id="5" files="pthread_mutex_lock/s-c1.c" tag="pt:THR"> 15There is no limit on the number of different mutex having threads contending, at the same time. 16 </assertion> 17 <assertion id="6" files="pthread_cond_init/s-c.c" tag="pt:THR"> 18Condvar initialization then destruction does not consume any system resource -- for any kind of condvar. 19 </assertion> 20 <assertion id="7" files="pthread_cond_init/stress.c" tag="pt:THR"> 21Condvar Initialization and destruction duration does not depend on the number of condvars in use in the system -- for any kind of condvar. 22 </assertion> 23 <assertion id="8" files="pthread_cond_timedwait/s-c.c" tag="pt:THR"> 24Latency 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. 25 </assertion> 26 <assertion id="9" files="pthread_cond_timedwait/stress1.c,pthread_cond_wait/stress1.c" tag="pt:THR"> 27When 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. 28 </assertion> 29 <assertion id="10" files="pthread_cond_timedwait/stress2.c,pthread_cond_wait/stress2.c" tag="pt:THR"> 30When a cancel request unblocks the thread, it must not consume any pending condition signal request. 31 </assertion> 32 <assertion id="10" files="pthread_cond_wait/stress.c" tag="pt:THR"> 33No condition signaling (signal or broadcast) are lost (i.e. not received by at least one (wait) or all (broadcast) waiting threads). 34 </assertion> 35 <assertion id="11" files="pthread_create/s-c1.c" tag="pt:THR"> 36The thread creation time does not depend on the number of threads already created in the process. 37 </assertion> 38 <assertion id="12" files="pthread_mutex_trylock/stress.c" tag="pt:THR"> 39pthread_mutex_trylock never locks the mutex when it returns EBUSY. 40 </assertion> 41 <assertion id="13" files="pthread_exit/stress.c" tag="pt:THR"> 42pthread_exit() frees the thread resources. 43 </assertion> 44 <assertion id="14" files="pthread_self/stress.c" tag="pt:THR"> 45pthread_self() returns the thread ID. 46 </assertion> 47 <assertion id="15" files="fork/s-c1.c" tag="pt:THR"> 48The process creation time in a fork() does not depend on the number of processes already created in the system. 49 </assertion> 50 <assertion id="16" files="pthread_once/stress.c" tag="pt:THR"> 51The init_routine argument of pthread_once is never called 52more or less than once. 53 </assertion> 54 <assertion id="17" files="pthread_getschedparam/stress.c" tag="pt:THR"> 55pthread_getschedparam() always returns the scheduling parameters of the queried thread. 56 </assertion> 57 <assertion id="18" files="pthread_kill/stress.c" tag="pt:THR"> 58Heavy signal delivery with pthread_kill() does not break the system, and no unpending signal get lost. 59 </assertion> 60 <assertion id="19" files="pthread_cancel/stress.c" tag="pt:THR"> 61Heavy cancelation does not break the system or the application. 62 </assertion> 63 <assertion id="20" files="sem_open/s-c1.c" tag="pt:SEM"> 64The sem_open and sem_close duration does not depend on the number of opened 65named semaphores. 66 </assertion> 67 <assertion id="21" files="sem_init/s-c1.c" tag="pt:SEM"> 68The sem_init and sem_destroy duration does not depend on the number of opened 69unnamed semaphores. 70 </assertion> 71 <assertion id="22" files="sem_getvalue/stress.c" tag="pt:SEM"> 72The sem_getvalue always returns the value of the semaphore at a given time 73during the call into the sval argument. 74 </assertion> 75</assertions> 76