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
0000354 [1003.1(2008)/Issue 7] System Interfaces Comment Omission 2010-11-13 14:16 2020-02-10 15:19
Reporter jilles View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Jilles Tjoelker
Organization
User Reference
Section pthread_mutex_lock
Page Number 1639
Line Number 52743
Interp Status Approved
Final Accepted Text See Note: 0000656
Summary 0000354: limit on the number of owned robust mutexes
Description With non-robust mutexes, in the usual implementation only threads
blocked on a mutex use kernel memory. The ownership of a mutex is stored
in the mutex itself, in userland. Because a thread can only be blocked on one mutex at a time, this limits the kernel memory usage based on the number of threads.

With robust mutexes, additional kernel involvement is required (since
even a SIGKILL must wake up a thread in another process waiting for the
mutex). Either the kernel maintains a list of owned robust mutexes per
thread, or userland maintains such a list and provides the kernel with a
pointer to it.

In either case, there needs to be a limit on the number of mutexes owned.
In the former case, kernel memory is a limited resource; in the latter case,
an excessively long or cyclic list must not lead to an endless loop.

The glibc+linux implementation uses a userland-maintained list and
treats this problem in a strange way. pthread_mutex_lock() never fails
because the list is too long. Instead, when the process terminates, the
part of the list beyond the kernel's limit is ignored and those mutexes
are stuck forever. The limit is probably so high it is not an issue in
practice, but I still consider this unsatisfactory. (The same could be said
about the number of times a recursive mutex can be locked recursively, and
that is specified in some way.)
Desired Action Add a new failure condition to pthread_mutex_lock(), for example
[EAGAIN] The mutex is a robust mutex and the limit on the number of robust mutexes owned would be exceeded.

The most straightforward and predictable limit is a limit per thread.

Some minimum on the limit should probably be specified.
Tags issue8
Attached Files

- Relationships
has duplicate 0000988Closed 1003.1(2013)/Issue7+TC1 Additional error condition for pthread_mutex_lock, pthread_mutex_trylock 

-  Notes
(0000643)
msbrown (manager)
2011-01-05 21:32

 Proposed Action (following from Action Item for Mark Brown, see the minutes for the meeting of 2 Dec 2010):

Insert the following text as a new line, after line 52746 on page 1639:

[EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded.
(0000644)
geoffclare (manager)
2011-01-06 10:11

 If this change is made, then an equivalent change should also be made
for the following functions:

pthread_cond_timedwait()
pthread_cond_wait()
pthread_mutex_setprioceiling()
pthread_mutex_timedlock()

(They can all return EOWNERDEAD when they acquire a robust mutex, and
therefore would also be subject to this limit.)
(0000655)
msbrown (manager)
2011-01-27 14:17

 New Proposed Action:

For pthread_cond_timedwait() and pthread_cond_wait(), insert the following text as a new line, after line 51058 on page 1587:

[EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded.

For pthread_mutex_setprioceiling(), insert the following text as a new line, after line 52629 on page 1634:

[EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded.

For pthread_mutex_lock(), insert the following text as a new line, after line 52746 on page 1639:

[EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded.

For pthread_mutex_timedlock(), insert the following text as a new line, after line 52899 on page 1644:

[EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded.
(0000656)
Don Cragun (manager)
2011-01-27 16:30

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

The standard does not speak to this issue, and as such 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 changes noted in Note: 0000655
(0000706)
ajosey (manager)
2011-03-15 14:46

 Interpretation proposed 15 Mar 2011 for final 30 day review
(0000769)
ajosey (manager)
2011-04-26 15:11

 The interpretation is now approved.

- Issue History
Date Modified Username Field Change
2010-11-13 14:16 jilles New Issue
2010-11-13 14:16 jilles Status New => Under Review
2010-11-13 14:16 jilles Assigned To => ajosey
2010-11-13 14:16 jilles Name => Jilles Tjoelker
2010-11-13 14:16 jilles Section => pthread_mutex_lock
2010-11-13 14:16 jilles Page Number => 1639
2010-11-13 14:16 jilles Line Number => 52743
2011-01-05 21:32 msbrown Note Added: 0000643
2011-01-06 10:11 geoffclare Note Added: 0000644
2011-01-27 14:17 msbrown Note Added: 0000655
2011-01-27 16:30 Don Cragun Interp Status => Pending
2011-01-27 16:30 Don Cragun Final Accepted Text => See Note: 0000655
2011-01-27 16:30 Don Cragun Note Added: 0000656
2011-01-27 16:30 Don Cragun Status Under Review => Interpretation Required
2011-01-27 16:30 Don Cragun Resolution Open => Accepted As Marked
2011-01-27 16:31 Don Cragun Final Accepted Text See Note: 0000655 => See Note: 0000656
2011-01-27 16:31 Don Cragun Tag Attached: issue8
2011-03-15 14:46 ajosey Interp Status Pending => Proposed
2011-03-15 14:46 ajosey Note Added: 0000706
2011-04-26 15:11 ajosey Interp Status Proposed => Approved
2011-04-26 15:11 ajosey Note Added: 0000769
2015-10-09 08:30 geoffclare Relationship added has duplicate 0000988
2020-02-10 15:19 geoffclare Status Interpretation Required => Applied

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