The following issue has been SUBMITTED. 
Reported By:                Florian Weimer
Assigned To:                
Project:                    1003.1(2016)/Issue7+TC2
Issue ID:                   1115
Category:                   System Interfaces
Type:                       Clarification Requested
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       Florian Weimer 
Organization:               Red Hat 
User Reference:              
Section:                    pthread_mutex_lock 
Page Number:                unknown 
Line Number:                unknown 
Interp Status:              --- 
Final Accepted Text:         
Date Submitted:             2017-01-13 14:41 UTC
Last Modified:              2017-01-13 14:41 UTC
Summary:                    Lock acquisition state after pthread_mutex_lock with
The text currently says:

If mutex is a robust mutex and the owning thread terminated while holding
the mutex lock, a call to pthread_mutex_lock() may return the error value
[EOWNERDEAD] even if the process in which the owning thread resides has not
terminated. In these cases, the mutex is locked by the thread but the state
it protects is marked as inconsistent.

It is unclear to which thread “the thread” in the last sentence

The current text goes on with:

The application should ensure that the state is made consistent for reuse
and when that is complete call pthread_mutex_consistent(). If the
application is unable to recover the state, it should unlock the mutex
without a prior call to pthread_mutex_consistent(), after which the mutex
is marked permanently unusable.

Due to the ambiguity above, it is unclear whether the current thread (which
calls pthread_mutex_consistent()) has acquired the lock after the call, and
whether it is correct to call pthread_mutex_unlock() afterwards.
Desired Action: 
I suggest to replace “the thread” with “the thread which has called
pthread_mutex_lock() resulting in an [EOWNERDEAD] error”.

As a result, the mutex is in the acquired state, and it remains so after a
call pthread_mutex_consistent().  Then it's allowed to call
pthread_mutex_unlock() whether or not pthread_mutex_consistent() has been

Another implication is that because the new thread acquires the lock, only
one thread can return [EOWNERDEAD], and the others will block.  I do not
know if this matches actual implementation practice, but it is the only way
robust mutexes can recovery without external synchronization.

Issue History 
Date Modified    Username       Field                    Change               
2017-01-13 14:41 Florian Weimer New Issue                                    
2017-01-13 14:41 Florian Weimer Name                      => Florian Weimer  
2017-01-13 14:41 Florian Weimer Organization              => Red Hat         
2017-01-13 14:41 Florian Weimer Section                   => pthread_mutex_lock
2017-01-13 14:41 Florian Weimer Page Number               => unknown         
2017-01-13 14:41 Florian Weimer Line Number               => unknown         

Reply via email to