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

[1003.1(2008)/Issue 7 0000089]: threads and EOWNERDEAD

To: austin-group-l@xxxxxxxxxxxxx
Subject: [1003.1(2008)/Issue 7 0000089]: threads and EOWNERDEAD
From: Austin Group Bug Tracker <noreply@xxxxxxxxxxxxx>
Date: Mon, 29 Jun 2009 17:35:34 +0000
Keywords: [1003.1(2008)/Issue 7] System Interfaces
The following issue has been SUBMITTED. 
====================================================================== 
http://austingroupbugs.net/view.php?id=89 
====================================================================== 
Reported By:                msbrown
Assigned To:                ajosey
====================================================================== 
Project:                    1003.1(2008)/Issue 7
Issue ID:                   89
Category:                   System Interfaces
Type:                       Error
Severity:                   Objection
Priority:                   normal
Status:                     Under Review
Name:                       Mark Brown 
Organization:               IBM 
User Reference:              
Section:                    2.9.3 
Page Number:                508 
Line Number:                17536-17542 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2009-06-29 17:35 UTC
Last Modified:              2009-06-29 17:35 UTC
====================================================================== 
Summary:                    threads and EOWNERDEAD
Description: 
_____________________________________________________________________________
 OBJECTION                                        Enhancement Request
Number 19
 gwc:xxxxxxxxxxxxx                              Defect in XSH 2.9.3 (rdvk#
 1)
 [gwc 2.9.3 EOWNERDEAD]                         Fri, 9 Jan 2009 15:32:52
+0000

_____________________________________________________________________________

The second paragraph of 2.9.3 states:

     A thread shall become the owner of a mutex, m, when one of the
     following occurs:

         * It returns successfully from pthread_mutex_lock( ) with m as
           the mutex argument.

         * It returns successfully from pthread_mutex_trylock( ) with m
           as the mutex argument.

         * It returns successfully from pthread_mutex_timedlock( ) with
           m as the mutex argument.

         * It returns (successfully or not) from pthread_cond_wait() with
           m as the mutex argument (except as explicitly indicated
           otherwise for certain errors).

         * It returns (successfully or not) from pthread_cond_timedwait()
           with m as the mutex argument (except as explicitly indicated
           otherwise for certain errors).

 There are two problems with this:

 1. The first three bullet items do not account for the EOWNERDEAD
 error, for the named functions and the pthread_mutex_setprioceiling()
 function, where the mutex is acquired even though the call is not
 successful.

 2. The last two bullet items talk about explicit exceptions for errors
 which do not acquire the mutex, but there are no such exceptions
 stated on the pthread_cond_timedwait() page - instead it has a
 statement for EOWNERDEAD that the mutex is acquired, and a statement
 in the DESCRIPTION about pthread_cond_timedwait() timeouts: "When such
 timeouts occur, pthread_cond_timedwait() shall nonetheless release and
 re-acquire the mutex referenced by mutex."

Desired Action: 
On lines 17536-17538 (first 3 bullet items), change:

     It returns successfully from [...] with m as the mutex argument.

 to

     It calls [...] with m as the mutex argument and the call returns
     zero or EOWNERDEAD.

 After line 17538 (3rd bullet item) add a new bullet item:

     * It calls pthread_mutex_setprioceiling() with m as the mutex
       argument and the call returns EOWNERDEAD.

 Replace lines 17539-17542 (last 2 bullet items) with:

     * It calls pthread_cond_wait() with m as the mutex argument and
       the call returns zero or certain error numbers (see [xref to
       pthread_cond_timedwait() page]).

     * It calls pthread_cond_timedwait() with m as the mutex argument
       and the call returns zero or certain error numbers (see [xref to
       pthread_cond_timedwait() page]).

======================================================================

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