Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000121 [1003.1(2008)/Issue 7] System Interfaces Comment Enhancement Request 2009-07-12 08:48 2013-04-16 13:06
Reporter aas029 View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name aas029
Organization
User Reference
Section pthread_mutex_unlock
Page Number 1638
Line Number 52698
Interp Status Approved
Final Accepted Text Note: 0000159
Summary 0000121: 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.
Tags tc1-2008
Attached Files pdf file icon Mutex – Summary (POSIX 2004).pdf [^] (28,957 bytes) 2009-07-13 21:28

- Relationships

-  Notes
(0000158)
geoffclare (manager)
2009-07-13 08:47

These mutex type descriptions also appear on the
pthread_mutexattr_gettype() page; it also needs to be updated to
take robust mutexes into account. In addition, that page talks
about re-locking without taking into account the difference between
pthread_mutex_lock() and pthread_mutex_trylock().

It would be good if the duplication could be avoided, by having
the mutex type descriptions appear on one of these pages and just
referring to them on the other.
(0000159)
geoffclare (manager)
2009-07-13 11:22
edited on: 2009-10-13 08:45

Interpretation response
------------------------

The standard is unclear on this issue, and no conformance
distinction can be made between alternative implementations based
on this. This is being referred to the sponsor.


Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
This includes a fix to address the issues identified in the
original report and in Note: 0000158. This also includes a fix for
an omission in the EPERM error on the pthread_mutex_lock()
page.

On the pthread_mutexattr_gettype() page, remove the descriptions from
the list of mutex types (lines 53481 to 53504), leaving just the four
type names. After the list of names add:

    The mutex type affects the behavior of calls which lock and
    unlock the mutex. See [xref to pthread_mutex_lock()] for details.
    An implementation may map PTHREAD_MUTEX_DEFAULT to one of the
    other mutex types.


On the pthread_mutex_lock() page, replace the first five paragraphs
of the description (lines 52690 to 52711) with:

    The mutex object referenced by mutex shall be locked by a call to
    pthread_mutex_lock() that returns zero or EOWNERDEAD.
    If the mutex is already locked by another thread, the calling
    thread shall block until the mutex becomes available. This
    operation shall return with the mutex object referenced by mutex
    in the locked state with the calling thread as its owner.

    If a thread attempts to relock a mutex that it has already locked,
    pthread_mutex_lock() shall behave as described in the Relock column
    of the following table. If a thread attempts to unlock a mutex
    that it has not locked or a mutex which is unlocked,
    pthread_mutex_unlock() shall behave as described in the Unlock When
    Not Owner column of the following table.

    
    ______________________________________________________________________
    | Mutex Type   Robustness     Relock          Unlock When Not Owner   |
    |_____________________________________________________________________|
    |                                                                     |
    | normal       non-robust     deadlock        undefined behavior      |
    |                                                                     |
    | normal       robust         deadlock        error returned          |
    |                                                                     |
    | errorcheck   either         error returned  error returned          |
    |                                                                     |
    | recursive    either         recursive       error returned          |
    |                             (see below)                             |
    |                                                                     |
    | default      non-robust     undefined       undefined behavior[1]   |
    |                             behavior[1]                             |
    |                                                                     |
    | default      robust         undefined       error returned          |
    |                             behavior[1]                             |
    |_____________________________________________________________________|
    


    1. If the mutex type is PTHREAD_MUTEX_DEFAULT, the behavior of
    pthread_mutex_lock() may correspond to one of the three other
    standard mutex types as described in the table above. If it
    does not correspond to one of those three, the behavior is
    undefined for the cases marked [1].

    Where the table indicates recursive behavior, the mutex shall
    maintain the concept of a lock count. When a thread successfully
    acquires a mutex for the first time, the lock count shall be set
    to one. Every time a thread relocks this mutex, the lock count
    shall be incremented by one. Each time the thread unlocks the
    mutex, the lock count shall be decremented by one. When the lock
    count reaches zero, the mutex shall become available for other
    threads to acquire.


At line 52763 change the description of EPERM from:

    The mutex type is PTHREAD_MUTEX_ERRORCHECK or the mutex is a
    robust mutex, and the current thread does not own the mutex.

to:

    The mutex type is PTHREAD_MUTEX_ERRORCHECK or
    PTHREAD_MUTEX_RECURSIVE, or the mutex is a robust mutex, and the
    current thread does not own the mutex.

(0000161)
aas029 (reporter)
2009-07-13 21:15

I find a table like the one suggested by geoffclare to be the best way to summaries the info for the reader but more importantly make sure all cases are covered and in a consistent manner.

In fact, I had produced such table for myself which covers all possible operations on mutexes, mutex state, mutex current owner and mutex type. I have this in pdf form for the 2004 version (doesn't reflect 2008 updates but I'll upload it as an example). I'm not familiar with the standard's update process and format restriction. I can share my upcoming 2008 version if the standard is open to such summary suggestions. Actually I discovered the issue reported while trying to fill a 2008 version of the table.

- Issue History
Date Modified Username Field Change
2009-07-12 08:48 aas029 New Issue
2009-07-12 08:48 aas029 Status New => Under Review
2009-07-12 08:48 aas029 Assigned To => ajosey
2009-07-12 08:48 aas029 Name => aas029
2009-07-12 08:48 aas029 Section => pthread_mutex_unlock
2009-07-12 08:48 aas029 Page Number => using online version
2009-07-12 08:48 aas029 Line Number => using online version
2009-07-13 08:47 geoffclare Note Added: 0000158
2009-07-13 11:22 geoffclare Note Added: 0000159
2009-07-13 20:47 aas029 Issue Monitored: aas029
2009-07-13 21:15 aas029 Note Added: 0000161
2009-07-13 21:28 aas029 File Added: Mutex – Summary (POSIX 2004).pdf
2009-08-13 16:27 nick Page Number using online version => 1638
2009-08-13 16:27 nick Line Number using online version => 52698
2009-08-13 16:27 nick Interp Status => ---
2009-08-20 15:14 ajosey Interp Status --- => Pending
2009-08-20 15:14 ajosey Final Accepted Text => Note: 0000159
2009-08-20 15:14 ajosey Note Added: 0000198
2009-08-20 15:14 ajosey Status Under Review => Interpretation Required
2009-08-20 15:14 ajosey Resolution Open => Accepted As Marked
2009-09-17 15:41 nick Interp Status Pending => Proposed
2009-10-13 08:45 ajosey Note Edited: 0000159
2009-10-13 08:45 ajosey Note Deleted: 0000198
2009-10-13 08:46 ajosey Interp Status Proposed => Approved
2010-09-21 11:10 geoffclare Tag Attached: tc1-2008
2013-04-16 13:06 ajosey Status Interpretation Required => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker