uses the same condition variable in multiple calls,

 

by different threads to pthread_cond_wait()

 

or pthread_cond_timedwait(), but specifies

 

different mutexes. The debugger transfers the

 

execution control to the user and prints a

 

warning message when this condition is detected.

 

All threads that concurrently wait on any single

 

condition variable must specify the same

 

associated mutex. For example,the pthread

 

implementation does not allow thread 1 to

 

wait on condition variable A by specifying

 

mutex A, while thread 2 waits on the same

 

condition variable A by specifying mutex

 

B. This returns an EINVAL error to the

 

application. In contrast to this obvious EINVAL

 

error, the cv-multiple-mxsoption detects the

 

less-obvious and non-concurrent use of multiple

 

mutexes with the same condition variable by

 

different threads. This option detects potential

 

EINVAL errors that exist as a result of different

 

timings or execution paths.

 

This option is used to detect unintentional use

 

of multiple mutexes with the same condition

 

variable by different threads. In the case of

 

applications that use a dynamic pool of mutexes,

 

the cv-multiple-mxsoption is not required

 

because this usage is normal and expected

 

application behavior.

cv-wait-no-mx [onoff]

The set thread-check cv-wait-no-mx

 

[onoff] checks if the associated mutex of a

 

condition variable is locked when the thread calls

 

the pthread_cond_wait() routine. The

 

debugger transfers the execution control to the

 

user and prints a warning message when this

 

condition is detected. This check is not a POSIX.1

 

standard requirement for the

 

pthread_cond_wait() routine. It is an

 

additional check provided by WDB.

thread-exit-own-mutex

The set thread-check

[onoff]

thread-exit-own-mutex [onoff]

 

command checks if any thread has terminated

 

execution without unlocking the mutexes or

14.11 Thread Debugging Support 185