The Risks of Mutexes

Contents[Show]

Usage of mutexes seems extremely simple. There is a critical section in the code, which can only be accessed by a single thread at any point of time. It's ensured by a mutex m. The calls m.lock() and m.unlock() guarantee this exclusivity. But, the devil is in the details.

Deadlock

The different names for deadlocks are frightening. Some call them deadly embrace  (hug of death :-)? or kiss of death. But wait, what is a deadlock?

Deadlock
   A deadlock is a state, in which at least two threads are blocked because each thread is waiting for the release of some resource with which the other thread works before it releases its own resource.

The result of a deadlock is a total standstill. The Thread and usually the whole program is blocked forever. It is easy to produce a deadlock. Curious?

Exceptions and unknown code

std::mutex m;
m.lock();
sharedVariable= getVar();
m.unlock();

 

In case the unknown code in the function getVar() throws an exception, m.unlock() will not be called. Every attempt to ask for the mutex m will fail and the program will block. Forever. But that is not the only issue with that piece of code. It calls some (unknown to us) function get.Var(), while m.lock() is active. What will happen if the function getVar() tries to get the same lock? Of course, you know it. A deadlock.

Do you want to have a more visual example?

Lock mutexes in a different order

Deadlock

 

Thread 1 and Thread 2 need access to two resources in order to finish their work. Unfortunately, they ask for the resources which are protected by two mutexes in different order. In this case the thread executions will interleave in such a way that thread 1 gets mutex 1, then thread 2 gets mutex 2, and we have a standstill. Each thread wants to get the other's mutex. For this, thread has to wait for the release of the resource.

 

It's easy to express the picture in code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// deadlock.cpp

#include <iostream>
#include <chrono>
#include <mutex>
#include <thread>

struct CriticalData{
  std::mutex mut;
};

void deadLock(CriticalData& a, CriticalData& b){

  a.mut.lock();
  std::cout << "get the first mutex" << std::endl;
  std::this_thread::sleep_for(std::chrono::milliseconds(1));
  b.mut.lock();
  std::cout << "get the second mutex" << std::endl;
  // do something with a and b
  a.mut.unlock();
  b.mut.unlock();
  
}

int main(){

  CriticalData c1;
  CriticalData c2;

  std::thread t1([&]{deadLock(c1,c2);});
  std::thread t2([&]{deadLock(c2,c1);});

  t1.join();
  t2.join();

}

 

Thread t1 and thread t2 call the function deadlock (line 12 - 20). To process deadlock, both functions need the  CriticalData c1 and c2 (line 27 and 28). Because the objects c1 and c2 must be protected from shared access, they  have a mutex (to keep this example code short and simple CriticalData doesn't have any other methods or members apart from mutex)

Only a sleep about 1 Millisecond in line 16, and we have the deadlock.
 

deadlockCode

The only choice now is the press CTRL+C to kill the process.

What's next?

Honestly, the example will not boost your confidence in writing multithreading programs. Additionally, the complexity will increase to the power of 2 which each new mutex. The solution to the problem are locks because they encapsulate mutexes in a safe manner. How? Have a look here. (Proofreader Alexey Elymanov)

 

 

 

 

 

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, Marko, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, espkk, Louis St-Amour, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Neil Wang, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Tobi Heideman, Daniel Hufschläger, Red Trip, Alexander Schwarz, Tornike Porchxidze, Alessandro Pezzato, Evangelos Denaxas, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Satish Vangipuram, and Michael Dunsky.

 

Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, and Said Mert Turkal.

 

 

My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small

 

Seminars

I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Bookable (Online)

German

Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

New

Contact Me

Modernes C++,

RainerGrimmSmall

Tags: mutex

Comments   

0 #1 Jeannine 2017-01-31 05:22
I have learn a few just right sttuff here. Certainly value bookmarking for revisiting.
I wonder how much attempt you put to make such a magnificent informative site.
Quote

My Newest E-Books

Course: Modern C++ Concurrency in Practice

Course: C++ Standard Library including C++14 & C++17

Course: Embedded Programming with Modern C++

Course: Generic Programming (Templates)

Course: C++ Fundamentals for Professionals

Interactive Course: The All-in-One Guide to C++20

Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code

Visitors

Today 4993

Yesterday 7071

Week 41969

Month 202643

All 6851335

Currently are 214 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments