0000354: limit on the number of owned robust mutexes

ID	Project	Category	View Status	Date Submitted	Last Update

0000354	1003.1(2008)/Issue 7	System Interfaces	public	2010-11-13 14:16	2024-06-11 08:53

Reporter	jilles	Assigned To	ajosey
Priority	normal	Severity	Comment	Type	Omission
Status	Closed	Resolution	Accepted As Marked

Name	Jilles Tjoelker
Organization
User Reference
Section	pthread_mutex_lock
Page Number	1639
Line Number	52743
Interp Status	Approved
Final Accepted Text	See 0000354: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

msbrown 2011-01-05 21:32 manager bugnote:0000643	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.

geoffclare 2011-01-06 10:11 manager bugnote:0000644	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.)

msbrown 2011-01-27 14:17 manager bugnote:0000655	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.

Don Cragun 2011-01-27 16:30 manager bugnote:0000656	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 0000354:0000655

ajosey 2011-03-15 14:46 manager bugnote:0000706	Interpretation proposed 15 Mar 2011 for final 30 day review

ajosey 2011-04-26 15:11 manager bugnote:0000769	The interpretation is now approved.

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 0000354: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 0000354:0000655 => See 0000354: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
2024-06-11 08:53	agadmin	Status	Applied => Closed

View Issue Details

Relationships

Activities

Issue History