C++ – Does order of unlocking mutexes make a difference here

cdeadlockmultithreadingpthreads

Let's say I have two variables, protected_var1 and protected_var2. Let's further assume that these variables are updated via multiple threads, and are fairly independent in that usually one or the other but not both is worked on – so they both have their own mutex guard for efficiency.

Assuming:

-I always lock mutexes in order (mutex1 then mutex2) in my code in regions where both locks are required.

-Both mutexes are used many other places by them selves (like just lock mutex1, or just lock mutex2).

Does the order in which I unlock the mutexes at the end of a function using both make a difference in this situation?

void foo()
{
    pthread_mutex_lock(&mutex1);
    pthread_mutex_lock(&mutex2);

    int x = protected_var1 + protected_var2;

    pthread_mutex_unlock(&mutex1); //Does the order of the next two lines matter?
    pthread_mutex_unlock(&mutex2);
}

I was asked a question a long time ago in an interview regarding this situation, and I came out feeling that the answer was yes – the order of those two unlocks does matter. I cannot for the life of me figure out how a deadlock could result from this though if the locks are always obtained in the same order wherever both are used.

Best Answer

The order shouldn't matter, as long as you don't attempt to acquire another lock between the releases. The important thing is to always acquire the locks in the same order; otherwise, you risk a deadlock.

EDIT:

To expand on the constraint: You must establish a strict ordering among the mutexes, e.g. mutex1 precedes mutex2 (but this rule is valid for any number of mutexes). You may only request a lock on a mutex if you don't hold a mutex which comes after it in the order; e.g. you may not request a lock on mutex1 if you hold a lock on mutex2. Anytime these rules are respected, you should be safe. With regards to releasing, if you release mutex1, then try to reacquire it before releasing mutex2, you've violated the rule. In this regard, there may be some advantage in respecting a stack-like order: last acquired is always the first released. But it's sort of an indirect effect: the rule is that you cannot request a lock on mutex1 if you hold one on mutex2. Regardless of whether you had a lock on mutex1 when you acquired the lock on mutex2 or not.

Related Solutions

Recursive Lock (Mutex) vs Non-Recursive Lock (Mutex)

The difference between a recursive and non-recursive mutex has to do with ownership. In the case of a recursive mutex, the kernel has to keep track of the thread who actually obtained the mutex the first time around so that it can detect the difference between recursion vs. a different thread that should block instead. As another answer pointed out, there is a question of the additional overhead of this both in terms of memory to store this context and also the cycles required for maintaining it.

However, there are other considerations at play here too.

Because the recursive mutex has a sense of ownership, the thread that grabs the mutex must be the same thread that releases the mutex. In the case of non-recursive mutexes, there is no sense of ownership and any thread can usually release the mutex no matter which thread originally took the mutex. In many cases, this type of "mutex" is really more of a semaphore action, where you are not necessarily using the mutex as an exclusion device but use it as synchronization or signaling device between two or more threads.

Another property that comes with a sense of ownership in a mutex is the ability to support priority inheritance. Because the kernel can track the thread owning the mutex and also the identity of all the blocker(s), in a priority threaded system it becomes possible to escalate the priority of the thread that currently owns the mutex to the priority of the highest priority thread that is currently blocking on the mutex. This inheritance prevents the problem of priority inversion that can occur in such cases. (Note that not all systems support priority inheritance on such mutexes, but it is another feature that becomes possible via the notion of ownership).

If you refer to classic VxWorks RTOS kernel, they define three mechanisms:

mutex - supports recursion, and optionally priority inheritance. This mechanism is commonly used to protect critical sections of data in a coherent manner.
binary semaphore - no recursion, no inheritance, simple exclusion, taker and giver does not have to be same thread, broadcast release available. This mechanism can be used to protect critical sections, but is also particularly useful for coherent signalling or synchronization between threads.
counting semaphore - no recursion or inheritance, acts as a coherent resource counter from any desired initial count, threads only block where net count against the resource is zero.

Again, this varies somewhat by platform - especially what they call these things, but this should be representative of the concepts and various mechanisms at play.

C++ – Do the parentheses after the type name make a difference with new

Let's get pedantic, because there are differences that can actually affect your code's behavior. Much of the following is taken from comments made to an "Old New Thing" article.

Sometimes the memory returned by the new operator will be initialized, and sometimes it won't depending on whether the type you're newing up is a POD (plain old data), or if it's a class that contains POD members and is using a compiler-generated default constructor.

In C++1998 there are 2 types of initialization: zero and default
In C++2003 a 3rd type of initialization, value initialization was added.

Assume:

struct A { int m; }; // POD
struct B { ~B(); int m; }; // non-POD, compiler generated default ctor
struct C { C() : m() {}; ~C(); int m; }; // non-POD, default-initialising m

In a C++98 compiler, the following should occur:

new A - indeterminate value
new A() - zero-initialize
new B - default construct (B::m is uninitialized)
new B() - default construct (B::m is uninitialized)
new C - default construct (C::m is zero-initialized)
new C() - default construct (C::m is zero-initialized)

In a C++03 conformant compiler, things should work like so:

new A - indeterminate value
new A() - value-initialize A, which is zero-initialization since it's a POD.
new B - default-initializes (leaves B::m uninitialized)
new B() - value-initializes B which zero-initializes all fields since its default ctor is compiler generated as opposed to user-defined.
new C - default-initializes C, which calls the default ctor.
new C() - value-initializes C, which calls the default ctor.

So in all versions of C++ there's a difference between new A and new A() because A is a POD.

And there's a difference in behavior between C++98 and C++03 for the case new B().

This is one of the dusty corners of C++ that can drive you crazy. When constructing an object, sometimes you want/need the parens, sometimes you absolutely cannot have them, and sometimes it doesn't matter.

Best Answer

Related Solutions

Recursive Lock (Mutex) vs Non-Recursive Lock (Mutex)

C++ – Do the parentheses after the type name make a difference with new

Related Topic