Austin Group Defect Tracker

Aardvark Mark IV

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
0000759 [1003.1(2013)/Issue7+TC1] System Interfaces Comment Clarification Requested 2013-09-24 00:24 2013-10-17 15:40
Reporter shware_systems View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Mark Ziegast
Organization
User Reference
Section pthread_mutex_lock(), pthread_mutexattr_get, setrobust()
Page Number 1654, 1674
Line Number 53619, 54314
Interp Status ---
Final Accepted Text
Summary 0000759: Is "may fail" case adequately specified?
Description Re: #0748
"The problem is that if the "may fail" EOWNERDEAD case is not
supported, and the process containing the terminated thread does
not terminate, then the mutex cannot be acquired - any attempt to
do so will either block indefinitely, fail with EBUSY, or timeout."

Is this the only behavior considered normative for if EOWNERDEAD isn't supported, that it behave as a non-robust mutex? If so, it seems making that explicit may be needed.

For both here and mutex_lock( ) pages I think the language leaves open, at least for implementation provided mutexes, some degree of automatic attempt to make the protected state consistent and return success, but this isn't indicated. I can also see, though non-portable, returning a different error value, e.g. ETHREADDEAD, to differentiate from the process-died case. An implementation-defined signal being raised with mutex address as parameter also might be usable to make the state consistent in the signal handler and call mutex_consistent( ) there before the lock interfaces return so they succeed, or return ENOTRECOVERABLE instead directly. A SIGIGN on this signal could still return EOWNERDEAD.
Desired Action Clarify alternative portable behaviors for when EOWNERDEAD is not returned in the "thread died but app hasn't" may fail case, or provide cross reference to existing text.
Tags No tags attached.
Attached Files

- Relationships
related to 0000748Closed pthread_mutexattr_setrobust() and thread termination cases 

-  Notes
(0001928)
geoffclare (manager)
2013-10-17 15:40

 When an error is "may fail", it is optional whether an implementation
of the function detects the error condition. If the function detects
the condition it must return the specified error. If it doesn't detect
the condition, it carries on as if the condition hadn't occurred.

- Issue History
Date Modified Username Field Change
2013-09-24 00:24 shware_systems New Issue
2013-09-24 00:24 shware_systems Name => Mark Ziegast
2013-09-24 00:24 shware_systems Section => pthread_mutex_lock(), pthread_mutexattr_get, setrobust()
2013-09-24 00:24 shware_systems Page Number => 1654, 1674
2013-09-24 00:24 shware_systems Line Number => 53619, 54314
2013-10-17 15:32 nick Relationship added related to 0000748
2013-10-17 15:40 geoffclare Interp Status => ---
2013-10-17 15:40 geoffclare Note Added: 0001928
2013-10-17 15:40 geoffclare Status New => Closed
2013-10-17 15:40 geoffclare Resolution Open => Rejected

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