Blocking and Non-Blocking Algorithms

Blocking, non-blocking, lock-free and wait-free. Each of these terms describes a key characteristic of an algorithm when executed in a concurrent environment. So, reasoning about the runtime behaviour of your program often means to put your algorithm in the right bucket. Therefore, this post is about buckets.

An algorithm fall in one of two buckets: blocking or non-blocking.

Let's first talk about blocking.

Blocking

Intuitively, is quite clear, what blocking for an algorithm mean. But concurrency is not about intuition, it's about precise terms. The easiest way to define blocking is to define it with the help of non-blocking.

Non-blocking: An algorithm is called non-blocking if failure or suspension of any thread cannot cause failure or suspension of another thread.(Java concurrency in practice)

There is not any word about locking in this definition. That's right. Non-blocking is a wider term.

To block a program is quite easy. The typical use-case is to use more than one mutex and lock them in a different sequence. Nice timing and you have a deadlock. But there are a lot more ways to produce blocking behaviour.

What is happening? The creator thread locks in (1) the mutex. Now, the child thread executes (2). To get the mutex in expression (3), the creator thread has at first unlock it. But the creator thread will only unlock the mutex if the lockGuard (1) goes in (4) out of scope. That will never happen because the child thread has at first to lock the mutex coutMutex.

Let's have a look at the non-blocking algorithms.

Non-blocking

The main categories for non-blocking algorithms are lock-free and wait-free. Each wait-free algorithm is lock-free and each lock-free is non-blocking. Non-blocking and lock-free are not the same. There is an additional guarantee, called obstruction-free, which I will ignore in this post because it is not so relevant.

Non-blocking algorithms are typically implemented with CAS instructions. CAS stands for compare and swap. CAS is called compare_exchange_strong or compare_exchange_weak in C++.

I will in this post only refer to the strong version. For more information, read my previous post The Atomic Boolean. The key idea of both operations is that a call of atomicValue.compare_exchange_strong(expected, desired) obeys the following rules in an atomically fashion.

If the atomic comparison of atomicValue with expected returns true, atomicValue will be set in the same atomic operation to desired.

If the comparison returns false, expected will be set to atomicValue.

Let's know have a closer look at lock-free versus wait-free.

At first, the definition of lock-free and wait-free. Both definitions are quite similar. Therefore, it makes a lot of sense to define them together.

Lock-free: A non-blocking algorithm is lock-free if there is guaranteed system-wide progress.

Wait-free: A non-blocking algorithm is wait-free if there is guaranteed per-thread progress.

The algorithm fetch_mult (1) mutiplies an std::atomic shared by mult. The key observation is that there is a small-time window between the reading of the old value T oldValue = shared Load (2) and the comparison with the new value (3). Therefore, another thread can always kick in and change the oldValue. If you reason about such a bad interleaving of threads, you see, that there can be no per-thread progress progress guarantee.

Wait-free

If you reason about the lock-free algorithm in the last example you will see. A compare_exchange_strong call involves synchronisation. First you read the old value and than you update the new value if the initial condition already holds. If the initial condition hold, you publish the new value. If not, you do it once more if put the call in a while loop. Therefore compare_exchange_strong behaves like an atomic transaction.

Have a closer look at function add (1). There is no synchronisation involved in expression (2). The value 1 is just added to the atomic cnt.

And here is the output of the program. We always get 10000. Because 10 threads increment the value 1000 times.

For simplicity reason I ignored a few other guarantees in this post such as starvation-free as subset of blocking or wait-free bounded as subset of wait-free. You can read the details at the blog Concurrency Freaks.

What's next?

In the next post, I will write about a curiosity. It's the so called ABA problem which is a kind of false positive case for CAS instructions. That means, although it seems that old value of a CAS instruction is still the same, it changed in the meantime.