...
When the system is built on the following platform:
Red Hat Enterprise Linux Client release 5.5 (Tikanga)
kernel 2.6.18
gcc 4.3.5 with the --D_GNU_SOURCE flag
the above code works as expected. Waiter1 and waiter2 increment the variable once they are signaled, and the correct mutex is acquired after pthread_cond_wait returns in each thread.
The man page for pthread_cond_wait on this configuration says that it “may†fail with a return value of EINVAL if “different mutexes were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the same condition variable.†This However, this does not happen however.
Implementation Details: OS X
When the system is built on the following platform:
OS X 10.6.4 (Snow Leopard)
gcc 4.2.1
...
The man page for pthread_cond_wait()}] simply says that {{EINVAL will be returned if “The “the value specified by cond or the value specified by mutex is invalid.,†but it doesn’t say what invalid means.
Compliant Solution
This problem can either be solved either by always using the same mutex whenever a particular condition variable is used , or by using separate condition variables. Which one is better depends , depending on how the code is expected to work. Here we will use the “same mutex†solution.
...
Waiting on the same condition variable with two different mutexes could cause a thread to be signaled and resume execution with the wrong mutex locked. This could lead to unexpected program behavior if the same shared data were simultaneously accessed by two threads.
Therefore, the severity is medium because improperly accessing shared data could lead to data integrity violation. Likelihood is probable because in such an implementation an error code would not be returned, and remediation cost is high because detection and correction of this problem are both manual.
...