Order of mutex_lock return in C

Question

Lets say there are 3 threads A, B and C. And a mutex X

A calls pthread_mutex_lock on X.

B calls pthread_mutex_lock on X.

*

C calls pthread_mutex_lock on X.

A calls pthread_mutex_unlock on X.

**

Who will now be able to use the shared resource first? B or C? And what happens if I try to use pthread_destroy_mutex in *? in **?

' B or C?' - one of them. It's your job, as designer, to ensure that the order does not matter. — Martin James, Mar 05 '16 at 11:13
This is partially answered in [What is the `pthread_mutex_lock()` wake order with multiple threads waiting?](http://stackoverflow.com/questions/14947191/what-is-the-pthread-mutex-lock-wake-order-with-multiple-threads-waiting). — isedev, Mar 05 '16 at 11:14
The other question is answered in the POSIX standard: "Attempting to destroy a locked mutex results in undefined behavior." — isedev, Mar 05 '16 at 11:15
@MartinJames The order doesn't matter, but isn't important to know and not just accept as is? — NotGI, Mar 05 '16 at 11:36
@Keddy1201 no, it's not important to know. How could such knowledge be useful? In real software, the order of locking is unlikely to be guaranteed or preidictable, so what happens upon unlock is equally well-defined. If you think it matters, you are doing something wrong. — Martin James, Mar 05 '16 at 11:43
Similarly with pthread_destroy_mutex - just don't do it, and you won't have any problems with it. — Martin James, Mar 05 '16 at 11:45
@MartinJames What do you mean not use pthread_destroy_mutex? What is it for then? I disagree with you that's it's not important to know. — NotGI, Mar 05 '16 at 11:47
@MartinJames It's like not using free after using malloc, I disagree with you on that matter. — NotGI, Mar 05 '16 at 11:49
'I disagree with you that's it's not important to know.' OK, in actual real software, how would you put such knowledge of the internal workings of the mutex queue and OS scheduling policy to any practical use? The thread that gets execution first would depend on both those things, and current CPU core loading, and interrupts, and other factors that are unpredictable in general. You cannot know which thread will run first with any certainty, so you MUST design so that it does not matter:) — Martin James, Mar 05 '16 at 11:53
'It's like not using free after using malloc' - you're right, it's much more risky than that, which is why you should avoid explicitly doing it, if you possibly can. — Martin James, Mar 05 '16 at 11:55
What I meant was , that it's important to know that it depends on kernel and not remain clueless about it — NotGI, Mar 05 '16 at 12:00
Destroying synchro objects like mutexes/semaphores, can be easily and safely done when all those threads that might use them have been destroyed, ie. at process termination. The ony other way of trying to be sure that all possible threads will not use a mutex is to use yet another thread to join() with them all before destroying the mutex. Using join() is why so many multithreaded apps are abysmally poor, essentially unmanageable, refuse to shut down promptly etc. — Martin James, Mar 05 '16 at 12:01

score 2 · Accepted Answer · answered Mar 05 '16 at 11:16

Who will now be able to use the shared resource first?

That depends on the kernel scheduler implementation. Posix words it this way:

If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock() is called, resulting in the mutex becoming available, the scheduling policy shall determine which thread shall acquire the mutex.

And what happens if I try to use pthread_destroy_mutex in *? in **?

Again from the manual:

Attempting to destroy a locked mutex results in undefined behavior.

If you have any further doubts along these lines then suggest consulting the relevant man pages.

Order of mutex_lock return in C

1 Answers1