Linked by Elad Lahav on Thu 18th Feb 2016 19:27 UTC
QNX

A mutex is a common type of lock used to serialize concurrent access by multiple threads to shared resources. While support for POSIX mutexes in the QNX Neutrino Realtime OS dates back to the early days of the system, this area of the code has seen considerable changes in the last couple of years.

Thread beginning with comment 625015
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Mutex behavior
by elahav on Fri 19th Feb 2016 16:13 UTC in reply to "RE[2]: Mutex behavior"
elahav
Member since:
2009-05-28


sem_init(&sem, 1);
...
sem_wait(sem); // lock
// equivalent to mutex
sem_post(sem); // unlock (even in new thread)


This is not equivalent to a mutex. While a count-1 semaphore behaves similarly to a mutex, there are subtle, yet important, differences, resulting from a semaphore not having an owner:
1. Any thread can signal the semaphore, leading to a loss of mutual exclusion (which will go unnoticed until data corruption is observed).
2. No way to avoid priority inversion.

You may not care about these problems in this particular case, but it is important to understand the semaphore/mutex divide.

Reply Parent Score: 1

RE[4]: Mutex behavior
by Alfman on Fri 19th Feb 2016 16:58 in reply to "RE[3]: Mutex behavior"
Alfman Member since:
2011-01-28

elahav,

1. Any thread can signal the semaphore, leading to a loss of mutual exclusion (which will go unnoticed until data corruption is observed).


Notice in the link I provided earlier that the pthread mutex behavior is undefined for the conditions where one would try to signal from another thread. It means that no code which correctly uses the mutex is allowed to attempt to signal the mutex from another thread. The fact that the semaphore defines and/or behaves differently for those conditions doesn't make it any less suitable as a mutex in code which makes no assumptions about those conditions. For all conditions that are defined for the mutex, the semaphore works the same way.

In other words, I think the semaphore pseudocode I gave above would be a valid implementation of a pthread mutex.

Note that I agree with you that a mutex is generally the accepted mechanism to use to serialize access to a data structure, but I'm not able to come up with examples where a semaphore doesn't work...can you come up with any counter examples?

2. No way to avoid priority inversion.


Even with a mutex, a low priority thread can block a high priority thread. Am I misunderstanding you?

Edited 2016-02-19 17:03 UTC

Reply Parent Score: 2

RE[5]: Mutex behavior
by elahav on Fri 19th Feb 2016 17:58 in reply to "RE[4]: Mutex behavior"
elahav Member since:
2009-05-28

Notice in the link I provided earlier that the pthread mutex behavior is undefined for the conditions where one would try to signal from another thread


It may be undefined in the spec, but it is certainly defined if you are using error-checking mutexes, which is the default on QNX and optional on Linux.

Even with a mutex, a low priority thread can block a high priority thread. Am I misunderstanding you?


Read the article ;-) With priority inheritance (again, default on QNX, optional on Linux), the low priority thread will be boosted to the priority of the highest waiter until it relinquishes the mutex.

Reply Parent Score: 1