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 624996
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Mutex behavior
by elahav on Fri 19th Feb 2016 01:27 UTC in reply to "Mutex behavior"
elahav
Member since:
2009-05-28

If you are waiting on an event that can be generated by any, or even multiple, threads, then semaphores are not what you are looking for. Perhaps a condition variable?

Also, note that semaphores and mutexes, while sometimes confused for one another, achieve completely different tasks: the first are a synchronization (i.e., temporal) mechanism, the second a data-protection (i.e., spacial) mechanism. Search for "Concurrent Urban Legends" by Peter Buhr and Ashif Harji.

Interestingly, your original goal, that of explicitly handing over a mutex from one thread to another without releasing it is something that has come up several times in the past. It's not hard to implement, I'm just not sure that the semantics of such an operation are fully understood.

Reply Parent Score: 1

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

elahav,

If you are waiting on an event that can be generated by any, or even multiple, threads, then semaphores are not what you are looking for. Perhaps a condition variable?


No actually, the purpose of the mutex was really just to protect a data structure from concurrent access.

Interestingly, your original goal, that of explicitly handing over a mutex from one thread to another without releasing it is something that has come up several times in the past. It's not hard to implement, I'm just not sure that the semantics of such an operation are fully understood.



Once the error was tracked to the mutex, it wasn't hard to fix: just replace the mutex with a posix semaphore.

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


It's semantically identical to the mutex, with the benefit of having defined behavior across threads.

Edited 2016-02-19 02:54 UTC

Reply Parent Score: 2

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

elahav,

If you are waiting on an event that can be generated by any, or even multiple, threads, then semaphores are not what you are looking for. Perhaps a condition variable?



Oh sorry, you were talking about my other example.
Yes a pthread condition variable might work there, there are many options really.


AFAIK pthread condition variables only support mutex synchronization which can potentially block the sender when it needs to change the predicate condition variable. The block would only be momentary, but with asynchronous programming the main thread should not enter a wait state to wait on locks in other threads - it goes against the design. I felt a spinlock was the best choice here to protect the thread data queue. Both linux eventfd and semaphores (and even pipes) allow us to send events without risk of putting the main thread in a blocked state.

Reply Parent Score: 2

RE[3]: Mutex behavior
by elahav on Fri 19th Feb 2016 16:13 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