Defect report from : Michael Gonzalez , Universidad de Cantabria
(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
@ page 1096 line 34687-34692 section pthread_mutex_getprioceiling( ) objection
{1}
Problem:
Edition of Specification (Year): 2004
Defect code : 2. Omission
The current standard specifies the following for the
pthread_mutex_setprioceiling() function:
The pthread_mutex_setprioceiling() function either locks the mutex
if it is unlocked, or blocks until it can successfully lock the
mutex, then it changes the mutex's priority ceiling and releases
the mutex.
But it is silent about the possibility of having a deadlock, if the call is
made with the mutex already locked.
The pthread_mutex_lock() function has several specifications for this situation:
- If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection
shall not be provided. Attempting to relock the mutex causes
deadlock. ...
- If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking
shall be provided. If a thread attempts to relock a mutex that it
has already locked, an error shall be returned. ...
- If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to
recursively lock the mutex results in undefined behavior.
But nothing is said for pthread_mutex_setprioceiling(), nor are the possible
errors included in the errors section, which leads to an application developer
to think that it is possible to correctly call pthread_mutex_setprioceiling()
with the mutex locked.
In particular, this is a very interesting programming paradigm for changing the
priority ceiling, because to do it you often need to access the state protected
by the mutex, which of course you do with the mutex locked.
Action:
There are two alternatives: specify that you can call
pthread_mutex_setprioceiling with the mutex locked, or create a new function to
do that.
Alternative a)
Change the description to:
If the calling thread is not the current owner of the mutex, the
pthread_mutex_setprioceiling( ) function shall either lock the mutex if it is
unlocked, or block until it can successfully lock the mutex, then it shall
change the mutex’s priority ceiling and release the mutex. If the calling
thread is the owner of the mutex, the pthread_mutex_setprioceiling( ) function
shall change the mutex’s priority ceiling. In both cases, when the change is
successful, the previous value of the priority ceiling shall be returned in
old_ceiling. The process of locking the mutex need not adhere to the priority
protect protocol.
Alternative b)
Specify that if pthread_mutex_setprioceiling( ) is called with the mutex locked
there are undefined results (the error is detected depending on the kind of
mutex, as with the pthread_mutex_lock() operation)
In addition, create a new function, for example
pthread_mutex_setprioceilinglocked(), with the same profile as
pthread_mutex_setprioceiling( ) and the following description:
If the calling thread is the owner of the mutex, the
pthread_mutex_setprioceiling( ) function shall change the mutex’s priority
ceiling. The change shall only take effect when the mutex is later unlocked.
When the change is successful, the previous value of the priority ceiling shall
be returned in old_ceiling. If the calling thread is not the current owner of
the mutex, the pthread_mutex_setprioceiling( ) the results are undefined.
The rationale for "The change shall only take effect when the mutex is later
unlocked" is that otherwise, the priority of the thread could be inappropriate,
and a ceiling violation could happen. An alternative is to allow the ceiling
violation by saying: "After the change, the priority protection may not apply
for the current critical section, i.e., until the calling thread invokes
pthread_mutex_unlock() for that mutex.
|