HP gnu source-level debugger 5992-4701 manual Different mutexes. The debugger transfers

	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