Pthreads- 1 lock, 2 unlocks

Question

If I understand correctly, then foo1() fails to unlock &private_value_. As a result, foo2()'s thread_mutex_lock does not work since foo1() never released it.

What are the other consequences?

int main ( ... )

foo1();
foo2();

return 0;
}

foo1()
{
 pthread_mutex_lock(&private_value_);
 do something 
 // no unlock!
}

foo2()
{
 pthread_mutex_lock(&private_value_)
 do something
 pthread_mutex_unlock(&private_value_);
}

Answer 1

The mutex works fine. It's doing what it is meant to do. The thread will block after foo1() exits until the mutex is obtained by foo2.

Answer 2

If only foo2 gets called everything will run normal. If foo1 gets called then, if foo2 gets called or any other function that requires the mutex it will lock up forever.

Answer 3

This is why people migrate to languages that offer scope-based solutions, like C++ and RAII. The mutex is working as intended, but the writer of the first function forgot a small call, and now the application halts.

Answer 4

It's a bug if a lock is taken on a mutex and nothing ever releases the lock.

However, that doesn't necessarily mean that foo1() has to release the lock, but something must.

There are patterns where one function will acquire a lock, and another will release it. But you need to take special care that these more complex mutex handling patterns are coded correctly. You might be looking at an example of this (and the boiled-down snippet in the question doesn't include that additional complexity).

And as Neil Butterworth mentioned in a comment, there are many situations in C++ where a mutex will be managed by an RAII class, so the lock will be released automatically when the 'lock manager' object gets destroyed (often by going out of scope). In this case, it may not be obvious that the lock is being released, since that is done as a side effect of the variable merely going out of scope.

Answer 5

There seems to be some confusion here between how the program should have been written and how the program, as currently written, will behave.

This code will cause deadlock, and this does not indicate that there is something wrong with how the mutexes are working. They're working exactly how they are supposed to: If you try to re-acquire a non-recursive mutex that is already locked, your code will block until the mutex is unlocked. That's how it's supposed to work.

Since this code is single-threaded, the blocking in foo2 will never end, and so your program will deadlock and not progress. That is most likely not how the program should work (because it's not a very useful program that way). The error is not in how the mutexes are functioning, but in how the programmer chose to employ them. The programmer should have put an unlock call at the end of foo1.

Answer 6

No, it does not necessarily block. All depends on your private_value_ variable. pthread_mutex_t can show different behavior according to the properties that were set when the variable was initialized. See http://opengroup.org/onlinepubs/007908775/xsh/pthread_mutex_lock.html

Answer 7

To answer the question:

There are no other consequences other than a deadlock (since your example is single threaded and makes the calls synchronously)..