Page History

Mutexes are used to prevent multiple threads from causing a data race by 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 mutual exclusion (at At least one nonshareable resource must be held.),
Hold hold and wait (a A thread must hold a resource while awaiting availability of another resource.),
No no preemption (resources Resources cannot be taken away from a thread while they are in-use.), and
Circular circular wait (a A thread must await a resource held by another thread which is, in turn, awaiting a resource held by the first thread.).

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
lang	c

#include <mutex>
#include <thread>
 
class bank_accountBankAccount {
  int balance;
public:
  std::mutex balance_mutexbalanceMutex;
  bank_accountBankAccount() = delete;
  explicit bank_accountBankAccount(int initial_amountinitialAmount) : balance(initial_amountinitialAmount) {}
  int get_balance() const { return balance; }
  void set_balance(int amount) { balance = amount; }
};
 
int deposit(bank_accountBankAccount *from, bank_accountBankAccount *to, int amount) {
  std::lock_guard<std::mutex> from_lock(from->balance_mutex>balanceMutex);
 
  // Not enough balance to transfer.
  if (from->get_balance() < amount) {
    return -1; // Indicate error
  }
  std::lock_guard<std::mutex> to_lock(to->balance_mutex>balanceMutex);
 
  from->set_balance(from->get_balance() - amount);
  to->set_balance(to->get_balance() + amount);
 
  return 0;
}
 
void f(bank_accountBankAccount *ba1, bank_accountBankAccount *ba2) {
  // Perform the deposits.
  std::thread thr1(deposit, ba1, ba2, 100);
  std::thread thr2(deposit, ba2, ba1, 100);
  thr1.join();
  thr2.join();
}

...

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 BankAccount object is initialized.

Code Block

bgColor	#ccccff
lang	c

#include <atomic>
#include <mutex>
#include <thread>
 
class bank_accountBankAccount {
  static std::atomic<unsigned int> global_idglobalId;
  const unsigned int id;
  int balance;
public:
  std::mutex balance_mutexbalanceMutex;
  bank_accountBankAccount() = delete;
  explicit bank_accountBankAccount(int initial_amountinitialAmount) : id(global_idglobalId++), balance(initial_amountinitialAmount) {}
  unsigned int get_id() const { return id; }
  int get_balance() const { return balance; }
  void set_balance(int amount) { balance = amount; }
};

std::atomic<unsigned int> bank_accountBankAccount::global_idglobalId(1);
 
int deposit(bank_accountBankAccount *from, bank_accountBankAccount *to, int amount) {
  std::mutex *first;
  std::mutex *second;
 
  if (from->get_id() == to->get_id()) {
    return -1; // Indicate error
  }
 
  // Ensure proper ordering for locking.
  if (from->get_id() < to->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_lockfirstLock(*first);
  std::lock_guard<std::mutex> second_locksecondLock(*second);
 
  // Check for 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(bank_accountBankAccount *ba1, bank_accountBankAccount *ba2) {
  // Perform the deposits.
  std::thread thr1(deposit, ba1, ba2, 100);
  std::thread thr2(deposit, ba2, ba1, 100);
  thr1.join();
  thr2.join();
}

...

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
lang	c

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

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

  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(bank_accountBankAccount *ba1, bank_accountBankAccount *ba2) {
  // Perform the deposits.
  std::thread thr1(deposit, ba1, ba2, 100);
  std::thread thr2(deposit, ba2, ba1, 100);
  thr1.join();
  thr2.join();
}

...

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

Automated Detection

Tool

Version

Checker

Description

CodeSonar

Include Page

	c:CodeSonar_V
	c:CodeSonar_V

CONCURRENCY.LOCK.ORDER

Conflicting lock order

Coverity

6.5

DEADLOCK

Fully implemented

Helix QAC

Include Page

	Helix QAC_V
	Helix QAC_V

C++1772, C++1773

Parasoft C/C++test

9.5BD-TRS-DLOCK

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-CPP

Checks for deadlocks

Fully implemented

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	LCK07-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 CWE	CWE-764, Multiple Locks of a Critical Resource

Bibliography

[ISO/IEC 14882-2014]

Section

Subclause 30.4, "Mutual Exclusion"

Section

Subclause 30.4.3, "Generic Locking Algorithms"

Image Modified Image Modified Image Modified

Space shortcuts

Page tree

Versions Compared

Old Version 7

New Version Current

Key

Automated Detection

Related Vulnerabilities

Related Guidelines

Bibliography