Robust mutexes work across processes, not threads. It is only when a
process dies that the wakeup mechanism kicks in.
Robust mutexes are not supposed to recover from errors in your code
(which would be the inter-thread case - why do you have a thread exit
while holding a mutex?) but from situations you have less control over,
such as another process going down.

--Elad

On Fri, 2018-02-16 at 15:18 -0500, Tim Sowden(deleted) wrote:
> I have a question about how robust mutex's work under QNX 7.0.
> 
> I create my mutex as (lots of error checking omitted for simplicity):
> 
> pthread_mutex_t mMutex; 
> pthread_mutexattr_t mMutexAttr;   
> 
> // Robust and recursive
> pthread_mutexattr_init(&mMutexAttr);
> pthread_mutexattr_setrobust(&mMutexAttr, PTHREAD_MUTEX_ROBUST)
> pthread_mutexattr_setrecursive(&mMutexAttr, PTHREAD_RECURSIVE_ENABLE)
> // Initialize
> pthread_mutex_init(&mMutex, &mMutexAttr);
> 
> In my lock() routine my code is:
> 
> // Acquire the mutex
> int retVal = pthread_mutex_lock(&mMutex);
> 	
> if (retVal != EOK)
> {
>     if (retVal == EOWNERDEAD)
>     {
>         pthread_mutex_consistent(&mMutex);
>         printf("Mutex::lock() - Owner died holding mutex. Fixing
> state\n");
>     }
>     else
>     {
>         printf("Mutex::lock() - Error %s while trying to lock mutex!
> Mutex not locked!", strerror(retVal));
> 
>     }
> }
> else
> {
>     // Locked do some processing
> }
> 
> Now I'm in a multi-threaded application (not multi-process) and I see
> the following behavior:
> 
> 1) Thread A locks the mutex
> Thread B blocks when trying to lock.
> Kill Thread A.
> Thread B never acquires the mutex (I thought the robustness would
> wake B and let it acquire the Mutex with the EOWNERDEAD return code
> so I could cleanup and continue) and I'm deadlocked.
> 
> 2) Thread A locks the mutex
> Kill Thread A
> Thread B tries to lock. It gets return code of EINVAL not EOWNERDEAD?
> Once again my process is effectively broken.
> 
> So are robust mutexes implemented under QNX 7 and if so am I doing
> something wrong code wise to make them work? Or do I have to use the
> SyncMutexEvent() methodology instead (is there sample code)? My
> preference is Posix over QNX specific code for portability reasons.
> 
> TIA,
> 
> Tim
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post118589
> To cancel your subscription to this discussion, please e-mail ostech-
> core_os-unsubscribe@community.qnx.com

Hello Tim,

I had recently another kind of problem with a robust mutex (in ported legacy code). It seems to be a bug, but I don't 
know how to verify that because I don't have a QNX support deal.

So my current recommendation is: do not use PTHREAD_MUTEX_ROBUST on QNX!

My scenario is (attached a sample code):
1. one thread is blocked on pthread_cond_wait()
2. another thread cancels the thread
3. problem: the thread never quits (application blocks forever at pthread_join()).

In this scenario, my solution is to use pthread_cleanup_push() to handle mutex releasing.