Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Both thread safety and liveness are concerns when using condition variables. The thread-safety property requires that all objects maintain consistent states in a multithreaded environment [Lea 2000]. The liveness property requires that every operation or function invocation execute to completion without interruption; for example, there is no deadlock.

Condition variables must be used inside a while loop. (see See CON54-CPP. 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 condition_variable::wait() member function. This early test checks whether another thread has already satisfied the condition predicate and has sent a notification. Invoking wait() after the notification has been sent results in indefinite blocking.

...

The notify_one() member function unblocks one of the threads that are blocked on the specified condition variable at the time of the call. If multiple threads are waiting on the same condition variable, the scheduler can select any of those threads to be awakened (assuming that all threads have the same priority level).

The notify_all() member function unblocks all of the threads that are blocked on the specified condition variable at the time of the call. The order in which threads execute following a call to notify_all() is unspecified. Consequently, an unrelated thread could start executing, discover that its condition predicate is satisfied, and resume execution even though it was supposed to remain dormant.

For these reasons, threads must check the condition predicate after the wait() function returns. A while loop is the best choice for checking the condition predicate both before and after invoking wait().

...

This noncompliant code example uses five threads that are intended to execute sequentially according to the step level assigned to each thread when it is created (serialized processing). The currentStep variable holds the current step level and is incremented when the respective thread completes. Finally, another thread is signaled so that the next step can be executed. Each thread waits until its step level is ready, and the wait() call is wrapped inside a while loop, in compliance with CON54-CPP. Wrap functions that can spuriously wake up in a loop.

Code Block
bgColor#FFcccc
langc
#include <condition_variable>
#include <iostream>
#include <mutex>
#include <thread>
 
std::mutex mutex;
std::condition_variable cond;

void run_step(size_t myStep) {
  static size_t currentStep = 0;
  std::unique_lock<std::mutex> lk(mutex);

  std::cout << "Thread " << myStep << " has the lock" << std::endl;

  while (currentStep != myStep) {
    std::cout << "Thread " << myStep << " is sleeping..." << std::endl;
    cond.wait(lk);
    std::cout << "Thread " << myStep << " woke up" << std::endl;
  }

  // Do processing...
  std::cout << "Thread " << myStep << " is processing..." << std::endl;
  currentStep++;

  // Signal awaiting task.
  cond.notify_one();

  std::cout << "Thread " << myStep << " is exiting..." << std::endl;
}

int main() {
  constexpr size_t numThreads = 5;
  std::thread threads[numThreads];

  // Create threads.
  for (size_t i = 0; i < numThreads; ++i) {
    threads[i] = std::thread(run_step, i);
  }

  // Wait for all threads to complete.
  for (size_t i = numThreads; i != 0; --i) {
    threads[i - 1].join();
  }
}

...

Deadlock: Out-of-Sequence Step Value

Time

Thread #
(my_step)

current_step

Action

0

3

0

Thread 3 executes the first time: the predicate is false -> wait()

1

2

0

Thread 2 executes the first time:

predicate

the predicate is false -> wait()

2

4

0

Thread 4 executes

first

the first time: the predicate is false -> wait()

3

0

0

Thread 0 executes the first time: the predicate is true -> currentStep++; notify_one()

4

1

1

Thread 1 executes the first time: the predicate is true -> currentStep++; notify_one()

5

3

2

Thread 3 wakes up (scheduler choice): the predicate is false -> wait()

6

Thread exhaustion!

No

There are 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.

...

This compliant solution uses notify_all() to signal all waiting threads instead of a single random thread. Only the run_step() thread code from the noncompliant code example is modified, as follows:.

Code Block
bgColor#ccccff
langc
#include <condition_variable>
#include <iostream>
#include <mutex>
#include <thread>

std::mutex mutex;
std::condition_variable cond;

void run_step(size_t myStep) {
  static size_t currentStep = 0;
  std::unique_lock<std::mutex> lk(mutex);

  std::cout << "Thread " << myStep << " has the lock" << std::endl;

  while (currentStep != myStep) {
    std::cout << "Thread " << myStep << " is sleeping..." << std::endl;
    cond.wait(lk);
    std::cout << "Thread " << myStep << " woke up" << std::endl;
  }

  // Do processing ...
  std::cout << "Thread " << myStep << " is processing..." << std::endl;
  currentStep++;

  // Signal ALL waiting tasks.
  cond.notify_all();

  std::cout << "Thread " << myStep << " is exiting..." << std::endl;
}
 
// ... main() unchanged ...

Awakening all threads guarantees the liveness property because each thread will execute its condition predicate test, and exactly one will succeed and continue execution.

...

Another compliant solution is to use a unique condition variable for each thread (all associated with the same mutex). In this case, notify_one() wakes up only the thread that is waiting on it. This solution is more efficient than using notify_all() because only the desired thread is awakened.

Note that the condition The condition predicate of the signaled thread must be true; otherwise, a deadlock will occur.

Code Block
bgColor#ccccff
langc
#include <condition_variable>
#include <iostream>
#include <mutex>
#include <thread>

constexpr size_t numThreads = 5;

std::mutex mutex;
std::condition_variable cond[numThreads];

void run_step(size_t myStep) {
  static size_t currentStep = 0;
  std::unique_lock<std::mutex> lk(mutex);

  std::cout << "Thread " << myStep << " has the lock" << std::endl;

  while (currentStep != myStep) {
    std::cout << "Thread " << myStep << " is sleeping..." << std::endl;
    cond[myStep].wait(lk);
    std::cout << "Thread " << myStep << " woke up" << std::endl;
  }

  // Do processing ...
  std::cout << "Thread " << myStep << " is processing..." << std::endl;
  currentStep++;

  // Signal next step thread.
  if ((myStep + 1) < numThreads) {
    cond[myStep + 1].notify_one();
  }

  std::cout << "Thread " << myStep << " is exiting..." << std::endl;
}

int main() {
  std::thread threads[numThreads];

  // Create threads...
  for (size_t i = 0; i < numThreads; ++i) {
    threads[i] = std::thread(run_step, i);
  }

  // Wait for all threads to complete.
  for (size_t i = numThreads; i != 0; --i) {
    threads[i - 1].join();
  }

  return 0;
} main() unchanged ...

Risk Assessment

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

CON55-CPP

Low

Unlikely

Medium

P2

L3


Automated Detection

Tool

Version

Checker

Description

CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

CONCURRENCY.BADFUNC.CNDSIGNAL

Use of Condition Variable Signal

Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C++1778, C++1779
Klocwork
Include Page
Klocwork_V
Klocwork_V
CERT.CONC.UNSAFE_COND_VAR
Parasoft C/C++test

Include Page
Parasoft_V
Parasoft_V

CERT_CPP-CON55-a

Do not use the 'notify_one()' function when multiple threads are waiting on the same condition variable

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C++: CON55-CPP

Checks for multiple threads waiting for same condition variable (rule fully covered)

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

[IEEE Std 1003.1:2013]XSH, System Interfaces, pthread_cond_broadcast
XSH, System Interfaces, pthread_cond_signal
[Lea 2000]
 

...



...

Image Modified Image Modified Image Modified