Thread-Safe Queue - Two Serious Errors

by Rainer Grimm

First, I want to show you again the erroneous implementation from my last post to understand the context.

// monitorObject.cpp

#include <condition_variable>
#include <functional>
#include <queue>
#include <iostream>
#include <mutex>
#include <random>
#include <thread>

class Monitor {
public:
    void lock() const {
        monitMutex.lock();
    }

    void unlock() const {
        monitMutex.unlock();
    }

    void notify_one() const noexcept {
        monitCond.notify_one();
    }

    template <typename Predicate>
    void wait(Predicate pred) const {                 // (10)
        std::unique_lock<std::mutex> monitLock(monitMutex);
        monitCond.wait(monitLock, pred);
    }
  
private:
    mutable std::mutex monitMutex;
    mutable std::condition_variable monitCond;
};

template <typename T>                                  // (1)
class ThreadSafeQueue: public Monitor {
public:
    void add(T val){
        lock();
        myQueue.push(val);                             // (6)
        unlock();
        notify_one();
    }
  
    T get(){
        wait( [this] { return ! myQueue.empty(); } );  // (2)
        lock();
        auto val = myQueue.front();                    // (4)
        myQueue.pop();                                 // (5)
        unlock();
        return val;
    }

private:
    std::queue<T> myQueue;                            // (3)
};


class Dice {
public:
    int operator()(){ return rand(); }
private:
    std::function<int()> rand = std::bind(std::uniform_int_distribution<>(1, 6),
                                          std::default_random_engine());
};


int main(){
  
    std::cout << '\n';
  
    constexpr auto NumberThreads = 100;
  
    ThreadSafeQueue<int> safeQueue;                      // (7)

    auto addLambda = [&safeQueue](int val){ safeQueue.add(val);          // (8)
                                            std::cout << val << " "
                                            << std::this_thread::get_id() << "; ";
                                          };
    auto getLambda = [&safeQueue]{ safeQueue.get(); };  // (9)

    std::vector<std::thread> addThreads(NumberThreads);
    Dice dice;
    for (auto& thr: addThreads) thr = std::thread(addLambda, dice());

    std::vector<std::thread> getThreads(NumberThreads);
    for (auto& thr: getThreads) thr = std::thread(getLambda);

    for (auto& thr: addThreads) thr.join();
    for (auto& thr: getThreads) thr.join();
  
    std::cout << "\n\n";
   
}

Object Ownership

By Ilya Doroshenko

Since we know the rules of new and delete, namely new allocates and delete destroys, we never really cared about who is responsible for the object. This caused a lot of confusion in the past. For instance, some API codes from Win32 return strings that should be LocalFree()d, like FormatMessage or GetEnvironmentStrings. POSIX, on the other hand, has strdup as a common example of you should free it yourself. This model is confusing because you may have a lot of return statements, before which you should always call free or delete, depending on the operation. However, we have RAII since the very beginning of C++, which adds constructors and destructors. So, in 1998 resourceful people decided to add auto_ptr to the standard.

The premise was simple:

• a simple explicit constructor, that took raw pointer from new
• destroyed by either an explicit release/reset or a destructor on the end of the block

This was the first attempt at a structured cleanup. As time passed, the initial point began to crumble. More issues arose and the question came up: Who owns the data?

Parsing Time Stamps Faster with SIMD Instructions

by Daniel Lemire

You can generate time stamps using any programming language. In C, the following program will print the current time (universal, not local time):

We are interested in the problem of parsing these strings. In practice, this means that we want to ...

AddressSanitizer continue_on_error

by Jim Radigan

Monitor Object

by Rainer Grimm

Problem

If many threads access a shared object concurrently, the following challenges exist.

• Due to the concurrent access, the shared object must be protected from non-synchronized read and write operations to avoid data races.
• The necessary synchronization should be part of the implementation, not the interface.
• When a thread is done with the shared object, a notification should be triggered so the next thread can use the shared object. This mechanism helps avoid and improves the system's overall performance.
• After the execution of a member function, the invariants of the shared object must hold.

Solution

A client (thread) can access the Monitor Object's synchronized member functions, and due to the monitor lock, only one synchronized member function can run at any given time. Each Monitor Object has a monitor condition that notifies the waiting clients.

Finite State Machine with std::variant

by Bartlomiej Filipek

Let’s start with a basic example:

• we want to track a game player’s health status
• we’d like to respond to events like “Hit by a monster” or “Healing bonus.”
• when the health point goes to 0, then we have to restart the game only if there are some remaining lives available

Here’s a basic diagram with states and transitions:

New C++ features in GCC 13

by Marek Polacek

Like the article I wrote about GCC 10 and GCC 12, this article describes only new features implemented in the C++ front end; it does not discuss developments in the C++ language itself. Interesting changes in the standard C++ library that comes with GCC 13 are described in a separate blog post: New C features in GCC 13

Active Object

by Rainer Grimm

The Active Object decouples method invocation from method execution. The method invocation is performed on the client thread, but the method execution is on the Active Object. The Active Object has its thread and a list of method request objects (short request) to be executed. The client’s method invocation enqueues the requests on the Active Object’s list. The requests are dispatched to the servant.

When many threads access a shared object synchronized, the following challenges must be solved:

• A thread invoking a processing-intensive member function should not block the other threads invoking the same object for too long.
• It should be easy to synchronize access to a shared object.
• The concurrency characteristics of the executed requests should be adaptable to the concrete hardware and software.

Solving Undefined Behavior in Factories with constinit from C++20

by Bartlomiej Filipek

Let’s bring back the topic:

Here’s a typical factory function. It creates unique_ptr with ZipCompression or BZCompression based on the passed name/filename:

Here are some issues with this approach:

• Each time you write a new class, and you want to include it in the factory, you have to add another if in the Create() method. Easy to forget in a complex system.
• All the types must be known to the factory.
• In Create(), we arbitrarily used strings to represent types. Such representation is only visible in that single method. What if you’d like to use it somewhere else? Strings might be easily misspelled, especially if you have several places where they are compared.

All in all, we get a strong dependency between the factory and the classes.

But what if classes could register themselves? Would that help?

The Move Constructor That You Have to Declare, Even Though You Don’t Want Anyone to Actually Call It

by Raymond Chen

Blah blah blah C++ return value optimization (RVO), named return value optimization (NRVO), and copy elision.

RVO support was optional in C++11 but became mandatory in C++17. NRVO support remains optional (but recommended).

To allow NRVO in C++17 (or RVO and NRVO in C++11), a move constructor must be available, even though the compiler will not call it if the optimization is employed.

You may have a class that you want to participate in RVO or NRVO, but you also don’t want it to be moved. For example, it may contain a std::mutex, which is not movable. But you nevertheless have to declare a move constructor. What can you do?

Declare the move constructor, but...