Austin Group Defect Tracker

Aardvark Mark III

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000089 [1003.1(2008)/Issue 7] System Interfaces Objection Error 2009-06-29 17:35 2009-10-12 05:36
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Interpretation Required  
Name Geoff Clare
Organization
User Reference
Section 2.9.3
Page Number 508
Line Number 17536-17542
Interp Status Approved
Final Accepted Text Note: 0000182
Summary 0000089: 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]).
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0000182)
ajosey (manager)
2009-08-06 15:57
edited on: 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 => Note: 0000182

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