Dealing with Mutation: Guarded Suspension

Guarded Suspension applies a unique strategy to deal with mutation. It signals when it is done with its modification.

The guarded suspension basic variant combines a lock and a precondition that must be satisfied. If the precondition is not fulfilled, that checking thread puts itself to sleep. The checking thread uses a lock to avoid a race condition that may result in a data race or a deadlock.

Various variants of the Guarded Suspension exist:

The waiting thread can passively be notified about the state change or actively ask for the state change. In short, I call this push versus pull principle.
The waiting can be done with or without a time boundary.
The notification can be sent to one or all waiting threads.

I present in this post only the rough idea. For further information, I refer to posts I have already written.

Push versus Pull Principle

Let me start with the push principle.

Push Principle

You often synchronize threads with a condition variable or a future/promise pair. The condition variable or the promise sends the notification to the waiting thread. A promise has no notify_one or notify_all member function. Typically, a valueless set_value call is used to signal a notification. The following program snippets show the thread sending the notification and the waiting thread.

Condition Variable

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

void waitingForWork(){
    std::cout << "Worker: Waiting for work." << '\n';
    std::unique_lock<std::mutex> lck(mutex_);
    condVar.wait(lck, []{ return dataReady; });
    doTheWork();
    std::cout << "Work done." << '\n';
}

void setDataReady(){
    {
      std::lock_guard<std::mutex> lck(mutex_);
      dataReady = true;
    }
    std::cout << "Sender: Data is ready."  << '\n';
    condVar.notify_one();
}

Future/Promise Pair

void waitingForWork(std::future<void>&& fut){

    std::cout << "Worker: Waiting for work." << std::endl;
    fut.wait();
    doTheWork();
    std::cout << "Work done." << std::endl;

}

void setDataReady(std::promise<void>&& prom){

    std::cout << "Sender: Data is ready."  << std::endl;
    prom.set_value();

}

Pull Principle

Instead of passively waiting for the state change, you can actively ask for it. This pull principle is not natively supported in C++ but can be, for example, implemented with atomics.

std::vector<int> mySharedWork;
std::atomic<bool> dataReady(false);

void waitingForWork(){
    std::cout << "Waiting " << '\n';
    while (!dataReady.load()){                
        std::this_thread::sleep_for(std::chrono::milliseconds(5));
    }
    mySharedWork[1] = 2;                     
    std::cout << "Work done " << '\n';
}

void setDataReady(){
    mySharedWork = {1, 0, 3};                  
    dataReady = true;                          
    std::cout << "Data prepared" << '\n';
}

Waiting with and without Time Boundary

A condition variable and a future have three member functions for waiting: wait, wait_for, and wait_until. The wait_for variant requires a time duration, and the wait_until variant a time point.

The consumer thread waits for the time duration steady_clock::now() + dur. The future asks for the value; if the promise is not done, it displays its id: this_thread::get_it().

void producer(promise<int>&& prom){
    cout << "PRODUCING THE VALUE 2011\n\n"; 
    this_thread::sleep_for(seconds(5));
    prom.set_value(2011);
}

void consumer(shared_future<int> fut,
              steady_clock::duration dur){
    const auto start = steady_clock::now();
    future_status status= fut.wait_until(steady_clock::now() + dur);
    if ( status == future_status::ready ){
        lock_guard<mutex> lockCout(coutMutex);
        cout << this_thread::get_id() << " ready => Result: " << fut.get() 
             << '\n';
    }
    else{
        lock_guard<mutex> lockCout(coutMutex);
        cout << this_thread::get_id() << " stopped waiting." << '\n';
    }
    const auto end= steady_clock::now();
    lock_guard<mutex> lockCout(coutMutex);
    cout << this_thread::get_id() << " waiting time: " 
         << getDifference(start,end) << " ms" << '\n';
}

Notifying one or all waiting Threads

notify_one awakes one of the waiting threads, notify_all awakes all the waiting threads. With notify_one, you have no guarantee which one will be awakened. The other threads do stay in the wait state. This could not happen with a std::future, because there is a one-to-one association between the future and the promise. If you want to simulate a one-to-many association, use a std::shared_future instead of a std::future because a std::shared_future can be copied.

The following program shows a simple workflow with one-to-one and one-to-many associations between promises and futures.

// bossWorker.cpp

#include <future>
#include <chrono>
#include <iostream>
#include <random>
#include <string>
#include <thread>
#include <utility>

int getRandomTime(int start, int end){
  
  std::random_device seed;
  std::mt19937 engine(seed());
  std::uniform_int_distribution<int> dist(start,end);
  
  return dist(engine);
};

class Worker{
public:
  explicit Worker(const std::string& n):name(n){};
  
  void operator() (std::promise<void>&& preparedWork, 
                   std::shared_future<void> boss2Worker){
      
    // prepare the work and notfiy the boss
    int prepareTime= getRandomTime(500, 2000);
    std::this_thread::sleep_for(std::chrono::milliseconds(prepareTime));
    preparedWork.set_value();                                  // (5) 
    std::cout << name << ": " << "Work prepared after " 
              << prepareTime << " milliseconds." << '\n';

    // still waiting for the permission to start working
    boss2Worker.wait();
  }    
private:
  std::string name;
};

int main(){
  
  std::cout << '\n';
  
  // define the std::promise => Instruction from the boss
  std::promise<void> startWorkPromise;

  // get the std::shared_future's from the std::promise
  std::shared_future<void> startWorkFuture= startWorkPromise.get_future();

  std::promise<void> herbPrepared;
  std::future<void> waitForHerb = herbPrepared.get_future();
  Worker herb("  Herb");                                           // (1) 
  std::thread herbWork(herb, std::move(herbPrepared), startWorkFuture);
  
  std::promise<void> scottPrepared;
  std::future<void> waitForScott = scottPrepared.get_future();
  Worker scott("    Scott");                                      // (2) 
  std::thread scottWork(scott, std::move(scottPrepared), startWorkFuture);
  
  std::promise<void> bjarnePrepared;
  std::future<void> waitForBjarne = bjarnePrepared.get_future();
  Worker bjarne("      Bjarne");                                  // (3)
  std::thread bjarneWork(bjarne, std::move(bjarnePrepared), startWorkFuture);
  
  std::cout << "BOSS: PREPARE YOUR WORK.\n " << '\n';
  
  // waiting for the worker 
  waitForHerb.wait(), waitForScott.wait(), waitForBjarne.wait();  // (4)
  
  // notify the workers that they should begin to work
  std::cout << "\nBOSS: START YOUR WORK. \n" << '\n';
  startWorkPromise.set_value();                                   // (6)
  
  herbWork.join();
  scottWork.join();
  bjarneWork.join();
   
}

The key idea of the program is that the boss (main-thread) has three workers: herb (line 1), scott (line 3), and bjarne (line 3). A thread represents each worker. In line (4), the boss waits until all workers complete their work package preparation. This means each worker sends, after an arbitrary time, the notification to the boss that he is done. The worker-to-the-boss notification is a one-to-one relation because it uses a std::future (line 5). In contrast, the instruction to start the work is a one-to-many notification (line 6) from the boss to its workers. For this one-to-many notification, a std::shared_future is necessary.

What’s Next?

In my next post, I will focus on concurrent architecture and write about the Active Object.

A Short Break

I will take a short two weeks holiday break. My next post will be published on Monday, the 19th of June.

Post Views: 3,536

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS