...
Condition variables must be used inside a while loop. (see See CON36-C. Wrap functions that can spuriously wake up in a loop for more information.) . To guarantee liveness, programs must test the while loop condition before invoking the cnd_wait() function. This early test checks whether another thread has already satisfied the condition predicate and has sent a notification. Invoking the cnd_wait() function after the notification has been sent results in indefinite blocking.
...
In this example, all threads share a condition variable. Each thread has its own distinct condition predicate because each thread requires current_step to have a different value before proceeding. When the condition variable is signaled, any of the waiting threads can wake up.
The following table illustrates a possible scenario in which the liveness property is violated. If, by chance, the notified thread is not the thread with the next step value, that thread will wait again. No additional notifications can occur, and eventually the pool of available threads will be exhausted.
Deadlock: Out-of-Sequence Step Value
Time | Thread # |
| Action |
|---|---|---|---|
0 | 3 | 0 | Thread 3 executes first time: predicate is |
1 | 2 | 0 | Thread 2 executes first time: predicate is |
2 | 4 | 0 | Thread 4 executes first time: predicate is |
3 | 0 | 0 | Thread 0 executes first time: predicate is |
4 | 1 | 1 | Thread 1 executes first time: predicate is |
5 | 3 | 2 | Thread 3 wakes up (scheduler choice): predicate is |
6 | — | — | Thread exhaustion! No more threads to run, and a conditional variable signal is needed to wake up the others |
This noncompliant code example violates the liveness property.
...
Another compliant solution is to use a unique condition variable for each thread (all associated with the same mutex). In this case, cnd_signal() wakes up only the thread that is waiting on it. This solution is more efficient than using cnd_broadcast() because only the desired thread is awakened.
Note that the The condition predicate of the signaled thread must be true; otherwise, a deadlock will occur.
...
Failing to preserve the thread safety and liveness of a program when using condition variables can lead to indefinite blocking and denial of service (DoS).
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
CON38-C | Low | Unlikely | Medium | P2 | L3 |
Automated Detection
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
| CERT Oracle Secure Coding Standard for Java | THI02-J. Notify all waiting threads rather than a single thread |
Bibliography
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| CodeSonar |
| CONCURRENCY.BADFUNC.CNDSIGNAL | Use of Condition Variable Signal | ||||||
| Cppcheck Premium |
| premium-cert-con38-c | Fully implemented | ||||||
| Helix QAC |
| C1778, C1779 | |||||||
| Klocwork |
| CERT.CONC.UNSAFE_COND_VAR_C | |||||||
| Parasoft C/C++test |
| CERT_C-CON38-a | Use the 'cnd_signal()' function with a unique condition variable | ||||||
| Polyspace Bug Finder |
| CERT C: Rule CON38-C | Checks for multiple threads waiting on same condition variable (rule fully covered) |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Key here (explains table format and definitions)
Taxonomy | Taxonomy item | Relationship |
|---|---|---|
| CERT Oracle Secure Coding Standard for Java | THI02-J. Notify all waiting threads rather than a single thread | Prior to 2018-01-12: CERT: Unspecified Relationship |
Bibliography
| [IEEE Std 1003 |
| .1:2013] | XSH, System Interfaces, pthread_cond_broadcastXSH, System Interfaces, pthread_cond_signal |
| [Lea 2000] |
...
...