View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000988 | 1003.1(2013)/Issue7+TC1 | System Interfaces | public | 2015-10-08 12:15 | 2016-07-14 15:34 |
| Reporter | Florian Weimer | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Duplicate | ||
| 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. | ||||
|
|
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. |
|
|
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. |
|
|
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? |
|
|
This seems to be a duplicate of #354. |
|
|
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. |
| 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 |
