PROCESS_SHARED/ROBUST pthread_mutex_t dealocks instead of returning EOWNERDEAD

Question

In my case, I need some lock in shm so I used pthread_mutex_t object.

Each pthread_mutex_t will be initialized as below so it can be shared between processes and is able to retore if the process exits while holding it.

pthread_mutexattr_t attr;                                                                                                                                                                            
pthread_mutexattr_init(&attr);                                                                                                                                                                       
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);                                                                                                                                         
pthread_mutexattr_setrobust(&attr, PTHREAD_MUTEX_ROBUST);                                                                                                                                            
pthread_mutex_init(&m_lock, &attr);  

I tried to trigger the pthread_mutex_lock returns EOWNERDEAD case through steps below:

1. Start one process and create one pthread_mutex_t in shm as described above;
2. pthread_mutex_lock the lock in shm explicitly and exit the process;
3. Start another process, get the lock in shm and try to lock it again with pthread_mutex_lock;

The issue is that I observed in step 3 deadlock, i.e. the pthread_mutex_lock never returns.

But according to pthread mutex document, in this case the pthread_mutex_lock should return EOWNERDEAD, indicating the holding process exitted while holding the process.

Test env is :

1. 5.15.0-1033-aws Ubuntu 20.04 LTS
2. g++ --version g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

Answer 1

After investigation, I found the robust mutex in shm is only marked as inconsistent when holding process/thread exits abnormally.

When the process exits normally through exit(0) or main function returns successfully, the lock in shm is in consistent locked status, hence causes the next lock operation blocks forever.