SEI CERT C++ Coding Standard

Space shortcuts

Page tree

Versions Compared

Old Version 2

changes.mady.by.user David Keaton

Saved on

compared with

New Version Current

changes.mady.by.user Jill Britton

Saved on

Key

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

UNDER CONSTRUCTION

Mutexes are used to prevent multiple threads from causing a data race by accessing shared resources accessing the same shared resource at the same time. Sometimes, when locking mutexes, multiple threads hold each other's lock, and the program consequently deadlocks. Four conditions are required for deadlock to occur:

  • mutual exclusion (At least one nonshareable resource must be held.),
  • hold and wait (A thread must hold a resource while awaiting availability of another resource.),
  • no preemption (Resources cannot be taken away from a thread while they are in-use.), and
  • circular wait (A thread must await a resource held by another thread which is, in turn, awaiting a resource held by the first thread.).
  • Mutual exclusion
  • Hold and wait
  • No preemption
  • Circular wait

Deadlock needs all four conditions, so preventing deadlock requires preventing any one of the four conditions. One simple solution is to lock the mutexes in a predefined order, which prevents circular wait.

...

Code Block
bgColor#ffcccc
langc
#include <mutex>
#include <thread>
 
typedefclass structBankAccount {
  int balance;
public:
  std::mutex balance_mutexbalanceMutex;
} bank_account;
 
void create_bank_account(bank_account **ba, BankAccount() = delete;
  explicit BankAccount(int initialAmount) : balance(initialAmount) {}
                  int initialget_amountbalance() const {
 return bank_account *nba = new bank_account();
 
  nba->balance = initial_amount;
 
  *ba = nba;
}balance; }
  void set_balance(int amount) { balance = amount; }
};
 
int deposit(bank_accountBankAccount *from, bank_accountBankAccount *to, int amount) {
  std::lock_guard<std::mutex> from_guardlock(from->balance_mutex>balanceMutex);
 
  //* Not enough balance to transfer */.
  if (from->balance>get_balance() < amount) {
    return -1; //* Indicate error */
  }
  std::lock_guard<std::mutex> to_guardlock(to->balance_mutex>balanceMutex);
 
  from->set_balance(from->balance>get_balance() -= amount);
  to->set_balance(to->balance>get_balance() += amount);
 
  return 0;
}
 
intvoid main(void) {
  bank_account *ba1;
  bank_account *ba2;
 
  create_bank_account(&ba1, 1000);
  create_bank_account(&ba2, 1000);
 f(BankAccount *ba1, BankAccount *ba2) {
  /*/ Perform the deposits */.
  std::thread thr1(deposit, ba1, ba2, 100);
  std::thread thr2(deposit, ba2, ba1, 100);
  thr1.join();
  thr2.join();
  return 0;
}

Compliant Solution (Manual Ordering)

This compliant solution eliminates the circular wait condition by establishing a predefined order for locking in the deposit() function. Each thread will lock on the basis of the bank_account BankAccount ID, which is set when the bank_account struct BankAccount object is initialized.

Code Block
bgColor#ccccff
langc
#include <atomic>
#include <mutex>
#include <thread>
 
typedefclass structBankAccount {
  int balance;
 static std::mutex balance_mutexatomic<unsigned int> globalId;
 
  /* Should not change after initialization */
  const unsigned int id;
} bank_account  int balance;
 public:
unsigned int global_id = 1 std::mutex balanceMutex;
 
void create_bank_account(bank_account **ba, BankAccount() = delete;
  explicit BankAccount(int initialAmount) : id(globalId++), balance(initialAmount) {}
  unsigned int get_id() const { return id;  }
       int initialget_amountbalance() const {
 return bank_account *nba = new bank_account();
 
  nba->balance = initial_amount;
 
  nba->id = global_id++;
  *ba = nba;
}balance; }
  void set_balance(int amount) { balance = amount; }
};

std::atomic<unsigned int> BankAccount::globalId(1);
 
int deposit(bank_accountBankAccount *from, bank_accountBankAccount *to, int amount) {
  int result = -1;
  std::mutex *first;
  std::mutex *second;
 
  if (from->id>get_id() == to->id>get_id()) {
    return -1; //* Indicate error */
  }
 
  /*/ Ensure proper ordering for locking */.
  if (from->id>get_id() < to->id>get_id()) {
    first = &from->balance_mutex>balanceMutex;
    second = &to->balance_mutex>balanceMutex;
  } else {
    first = &to->balance_mutex>balanceMutex;
    second = &from->balance_mutex>balanceMutex;
  }
  std::lock_guard<std::mutex> first_guardfirstLock(*first);
  std::lock_guard<std::mutex> second_guardsecondLock(*second);
 
  //* Check Notfor enough balance to transfer.
  if (from->get_balance() >= amount) {
    from->set_balance(from->get_balance() - amount);
    to->set_balance(to->get_balance() + amount);
    return 0;
  }
  return -1;
}
 
void f(BankAccount *ba1, BankAccount *ba2) {
  // Perform the deposits.
  std::thread thr1(deposit, ba1, ba2, 100);
  std::thread thr2(deposit, ba2, ba1, 100);
  thr1.join();
  thr2.join();
}

Compliant Solution (std::lock())

This compliant solution uses Standard Template Library facilities to ensure that deadlock does not occur due to circular wait conditions. The std::lock() function takes a variable number of lockable objects and attempts to lock them such that deadlock does not occur [ISO/IEC 14882-2014]. In typical implementations, this is done by using a combination of lock(), try_lock(), and unlock() to attempt to lock the object and backing off if the lock is not acquired, which may have worse performance than a solution that locks in predefined order explicitly.

Code Block
bgColor#ccccff
langc
#include <mutex>
#include <thread>
 
class BankAccount {
  int balance;
public:
  std::mutex balanceMutex;
  BankAccount(from->balance) = delete;
  explicit BankAccount(int initialAmount) : balance(initialAmount) {}
  int get_balance() const { return balance; }
  void set_balance(int amount) { balance = amount; }
};
 
int deposit(BankAccount *from, BankAccount *to, int amount) {
  // Create lock objects but defer locking them until later.
  std::unique_lock<std::mutex> lk1(from->balanceMutex, std::defer_lock);
  std::unique_lock<std::mutex> lk2(to->balanceMutex, std::defer_lock);

  // Lock both of the lock objects simultaneously.
  std::lock(lk1, lk2);

  if (from->get_balance() >= amount) {
    from->set_balance(from->balance>get_balance() -= amount);
    to->set_balance(to->balance>get_balance() += amount);
    result =return 0;
  }
  return -1;
}
 
void f(BankAccount *ba1, BankAccount *ba2) {
  // Perform the deposits.
  std::thread thr1(deposit, ba1, ba2, 100);
  std::thread thr2(deposit, ba2, ba1, 100);
  return resultthr1.join();
  thr2.join();
}

Risk Assessment

Deadlock prevents multiple threads from progressing, halting program execution. A denial-of-service attack is possible if the attacker can create the conditions for deadlock.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

CON53-CPP

Low

Probable

Medium

P4

L3

...

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

Automated Detection

ToolVersionCheckerDescription
CodeSonar
Include Page
c:CodeSonar_V
c:CodeSonar_V
CONCURRENCY.LOCK.ORDERConflicting lock order
Coverity6.5DEADLOCKFully implemented
Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C++1772, C++1773
Parasoft C/C++test
9.5BD-TRS-DLOCKFully implemented
Include Page
Parasoft_V
Parasoft_V

CERT_CPP-CON53-a

Do not acquire locks in different order

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C++: CON53-CPPChecks for deadlocks

Related Vulnerabilities

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

Related Guidelines

CERT Oracle Secure Coding Standard for JavaLCK07-J. Avoid deadlock by requesting and releasing locks in the same order

SEI CERT C Coding Standard

CON35-C. Avoid deadlock by locking in a predefined order

MITRE CWECWE-764, Multiple Locks of a Critical Resource

...

Bibliography

[ISO/IEC 14882-2014]

Subclause 30.4, "Mutual Exclusion"
Subclause 30.4.3, "Generic Locking Algorithms"


Image Modified Image Modified Image Modified