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 625022
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Mutex behavior
by elahav on Fri 19th Feb 2016 17:58 UTC 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

RE[6]: Mutex behavior
by Alfman on Fri 19th Feb 2016 19:33 in reply to "RE[5]: Mutex behavior"
Alfman Member since:
2011-01-28

elahav,

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.


It's true error checking extensions can help catch code that triggers undefined mutex behavior. One could implement the same optional error checking with semaphores too, but I think it is unfortunate that useful scenarios were left undefined in the first place. Now we're forced to "reinvent the wheel" just to work around the cases for which a mutex is not properly defined. Alas, it is what it is.


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.


I did read it, thank you for the article by the way.

This is a good point, you can't really bump the priority of unequal threads when the kernel doesn't know which thread will release a lock. Maybe there should be a well to tell it.

Reply Parent Score: 2

RE[7]: Mutex behavior
by dpJudas on Fri 19th Feb 2016 19:56 in reply to "RE[6]: Mutex behavior"
dpJudas Member since:
2009-12-10

Now we're forced to "reinvent the wheel" just to work around the cases for which a mutex is not properly defined. Alas, it is what it is.

It is not "properly defined" to increase the chance more optimal implementations are possible without having to support weird usages such as "lock mutex in one thread and unlock in another".

Exactly why you had to lock it in one thread and release it in another is still not clear (to me), but I'm guessing there is a good chance that some of the other pthread primitives available would have been a better fit for the problem at hand.

Reply Parent Score: 2