Email List: Xaustin-group-lX
[All Lists]

[1003.1(2008)/Issue 7 0000121]: robust mutex unlock by a thread that doe

To: austin-group-l@xxxxxxxxxxxxx
Subject: [1003.1(2008)/Issue 7 0000121]: robust mutex unlock by a thread that does not own the mutex
From: Austin Group Bug Tracker <noreply@xxxxxxxxxxxxx>
Date: Sun, 12 Jul 2009 08:48:48 +0000
Keywords: [1003.1(2008)/Issue 7] System Interfaces
The following issue has been SUBMITTED. 
====================================================================== 
http://austingroupbugs.net/view.php?id=121 
====================================================================== 
Reported By:                aas029
Assigned To:                ajosey
====================================================================== 
Project:                    1003.1(2008)/Issue 7
Issue ID:                   121
Category:                   System Interfaces
Type:                       Enhancement Request
Severity:                   Comment
Priority:                   normal
Status:                     Under Review
Name:                       aas029 
Organization:                
User Reference:              
Section:                    pthread_mutex_unlock 
Page Number:                using online version 
Line Number:                using online version 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2009-07-12 08:48 UTC
Last Modified:              2009-07-12 08:48 UTC
====================================================================== 
Summary:                    robust mutex unlock by a thread that does not own
the mutex
Description: 
The interface for pthread_mutex_lock(), _trylock(), _unlock() seems to have
a conflict between the following statements:

1. "If the mutex type is PTHREAD_MUTEX_NORMAL ... If a thread attempts to
unlock a mutex that it has not locked or a mutex which is unlocked,
undefined behavior results.
..... 
If the mutex type is PTHREAD_MUTEX_DEFAULT, ... Attempting to unlock the
mutex if it was not locked by the calling thread results in undefined
behavior. "

AND:
2. "The pthread_mutex_unlock() function shall fail if:
[EPERM] The mutex type is PTHREAD_MUTEX_ERRORCHECK or the mutex is a
robust mutex, and the current thread does not own the mutex."

The involved scenario is:
An attempt to unlock a robust mutex of type NORMAL or DEFAULT by a thread
that does not own it. 

If I understand #2 above correctly, invoking the above scenario shall
result in EPERM. This is clearly a defined behavior. On the other hand, the
statements quoted in #1 above suggest the outcome for the same scenario
(among other ones) is undefined behavior. There is no distinction made for
robust mutexes. 

Desired Action: 
Update the wording of the statements quoted in #1 in the description of
this issue. Here is one possible suggestion:

If the mutex type is PTHREAD_MUTEX_NORMAL ... If a thread attempts to
unlock a mutex which is unlocked, undefined behavior results. Further, if a
thread attempts to unlock a mutex that it has not locked and the mutex is
not robust, undefined behavior results.
.....
..... 
If the mutex type is PTHREAD_MUTEX_DEFAULT, ... If a thread attempts to
unlock a mutex that it has not locked and the mutex is not robust,
undefined behavior results. 
======================================================================

<Prev in Thread] Current Thread [Next in Thread>