View Issue Details

IDProjectCategoryView StatusLast Update
00000891003.1(2008)/Issue 7System Interfacespublic2013-04-16 13:06
Reportergeoffclare Assigned Toajosey  
PrioritynormalSeverityObjectionTypeError
Status ClosedResolutionAccepted 
NameGeoff Clare
Organization
User Reference
Section2.9.3
Page Number508
Line Number17536-17542
Interp StatusApproved
Final Accepted Text0000089:0000182
Summary0000089: 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 ActionOn 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]).
Tagstc1-2008

Activities

ajosey

2009-08-06 15:57

manager   bugnote:0000182

Last edited: 2009-10-12 05:35

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):
-------------------------------------------------------

Make the change suggested by the submitter

Issue History

Date Modified Username Field Change
2009-06-29 17:35 msbrown New Issue
2009-06-29 17:35 msbrown Status New => Under Review
2009-06-29 17:35 msbrown Assigned To => ajosey
2009-06-29 17:35 msbrown Name => Mark Brown
2009-06-29 17:35 msbrown Organization => IBM
2009-06-29 17:35 msbrown Section => 2.9.3
2009-06-29 17:35 msbrown Page Number => 508
2009-06-29 17:35 msbrown Line Number => 17536-17542
2009-06-29 17:35 msbrown Status Under Review => Resolved
2009-06-29 17:35 msbrown Resolution Open => Accepted
2009-07-01 17:08 msbrown Name Mark Brown => Geoff Clare
2009-07-01 17:08 msbrown Organization IBM =>
2009-07-01 17:08 msbrown Reporter msbrown => geoffclare
2009-08-06 15:57 ajosey Note Added: 0000182
2009-08-06 15:57 ajosey Status Resolved => Interpretation Required
2009-08-11 16:36 Don Cragun Interp Status => Pending
2009-09-17 15:41 nick Interp Status Pending => Proposed
2009-10-12 05:35 ajosey Note Edited: 0000182
2009-10-12 05:36 ajosey Interp Status Proposed => Approved
2009-10-12 05:36 ajosey Final Accepted Text => 0000089:0000182
2010-09-20 09:25 geoffclare Tag Attached: tc1-2008
2013-04-16 13:06 ajosey Status Interpretation Required => Closed