Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000988 [1003.1(2013)/Issue7+TC1] System Interfaces Editorial Clarification Requested 2015-10-08 12:15 2016-07-14 15:34
Reporter Florian Weimer View Status public  
Assigned To
Priority normal Resolution Duplicate  
Status Closed  
Name Florian Weimer
Organization Red Hat
User Reference
Section pthread_mutex_lock
Page Number unknown
Line Number unknown
Interp Status ---
Final Accepted Text
Summary 0000988: Additional error condition for pthread_mutex_lock, pthread_mutex_trylock
Description On Linux, a process can only reliably lock ROBUST_LIST_LIMIT mutexes at the same time. This means that pthread_mutex_lock and pthread_mutex_trylock should fail if this limit is exceeded. The current specification does not document this error condition.

(It is not possible to check this limit at pthread_mutex_init time because the mutex could have been created by another process.)
Desired Action Specify EAGAIN as an error code for this failure.
Tags No tags attached.
Attached Files

- Relationships
duplicate of 0000354Appliedajosey 1003.1(2008)/Issue 7 limit on the number of owned robust mutexes 

-  Notes
(0002860)
shware_systems (reporter)
2015-10-08 12:56

That is something for LINUX to address, as POSIX does not appear to impose that restriction. It makes allowance for it by EAGAIN in pthread_mutex_init(), as to how many can be owned, but does not impose a per process limit on how many can be referenced by sharing. The implicit limit on that is available memory, that I can see.
(0002861)
Florian Weimer (reporter)
2015-10-08 13:22

Unfortunately, pthread_mutex_init is not the only way to add mutexes to a process which can be locked later. If we do not check the limit at lock time, we would have to check at mmap time if the mapping contains any robust mutexes, and proactively fail mmap if the implementation limit is exceeded.
(0002862)
shware_systems (reporter)
2015-10-08 14:01

I would say it is more on those other ways to respect any implementation-defined limits of this nature, if they are populating the per-process structures with data directly. After a mmap() the process still has to init references to locks in that address space; wouldn't trying to reuse another process's handle directly count against that previous process, not the one doing the new map?
(0002867)
jilles (reporter)
2015-10-08 22:08

This seems to be a duplicate of #354.
(0002868)
shware_systems (reporter)
2015-10-09 11:15

Mostly... The resolution of #354 is per-system, not per-process, though, and by the wording it's a may fail error, depending on implementation model. I don't have the 2008 pdf handy to compare line numbers. The Rationale also could have something that explains that it may not occur on all platforms, so this could be a child issue.

- Issue History
Date Modified Username Field Change
2015-10-08 12:15 Florian Weimer New Issue
2015-10-08 12:15 Florian Weimer Name => Florian Weimer
2015-10-08 12:15 Florian Weimer Organization => Red Hat
2015-10-08 12:15 Florian Weimer Section => pthread_mutex_lock
2015-10-08 12:15 Florian Weimer Page Number => unknown
2015-10-08 12:15 Florian Weimer Line Number => unknown
2015-10-08 12:56 shware_systems Note Added: 0002860
2015-10-08 13:22 Florian Weimer Note Added: 0002861
2015-10-08 14:01 shware_systems Note Added: 0002862
2015-10-08 22:08 jilles Note Added: 0002867
2015-10-09 08:30 geoffclare Relationship added duplicate of 0000354
2015-10-09 11:15 shware_systems Note Added: 0002868
2016-07-14 15:34 Don Cragun Interp Status => ---
2016-07-14 15:34 Don Cragun Status New => Closed
2016-07-14 15:34 Don Cragun Resolution Open => Duplicate


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