Filter
Top Products
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-mxs option 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-mxs option is not required
because this usage is normal and expected
application behavior.
cv-wait-no-mx [on|off] The set thread-check cv-wait-no-mx
[on|off] 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
[on|off]
The set thread-check
thread-exit-own-mutex [on|off]
command checks if any thread has terminated
execution without unlocking the mutexes or
14.11 Thread Debugging Support 185