Anonymous | Login | 2023-12-06 14:35 UTC |
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 | |||||||
0000864 | [1003.1(2013)/Issue7+TC1] System Interfaces | Editorial | Clarification Requested | 2014-08-08 23:03 | 2023-08-10 15:41 | |||||||
Reporter | dalias | View Status | public | |||||||||
Assigned To | ||||||||||||
Priority | normal | Resolution | Open | |||||||||
Status | New | |||||||||||
Name | Rich Felker | |||||||||||
Organization | musl libc | |||||||||||
User Reference | ||||||||||||
Section | unknown | |||||||||||
Page Number | unknown | |||||||||||
Line Number | unknown | |||||||||||
Interp Status | --- | |||||||||||
Final Accepted Text | ||||||||||||
Summary | 0000864: Insufficient specification of storage requirements for synchronization objects | |||||||||||
Description |
This report actually covers multiple questions, mostly related to process-shared synchronization objects, but they all stem from a lack of specification of the storage requirements for synchronization objects, which is the core issue I'm reporting. The rationale for pthread_mutexattr_init and pthread_mutexattr_destroy provide the only documentation I can find regarding the intended supported usage cases for process-shared mutexes and their storage in shared memory, but this text is not normative. Here are some specific questions I have: 1. Is it permitted to perform operations on a non-process-shared synchronization objects if they are stored in shared memory by the process that created them, but only used by this process? If so, if this shared memory is mapped more than once at different addresses, is it permitted to access the non-process-shared object mapped at an address different from the address where it was originally initialized? 2. If storage for a synchronization object is deallocated without first destroying the object, is the behavior undefined? The answer to this question has implications for shared memory objects which have already been unlinked and for which there are no file descriptors, which cease to exist when the last process with a mapping unmaps them -- in this case the deallocation of storage is not explicit. 3. Under what conditions can the storage for a synchronization object in MAP_SHARED storage be unmapped without destroying it? As an example of a difficult case, if two threads in a process both access a mutex via a common shared memory mapping, is thread A permitted to unmap the memory after successfully locking and unlocking the mutex if (1) thread B was the previous owner of the mutex, (2) thread B will not attempt to access the mutex again, but (3) due to scheduling, thread B has not actually finished returning from the pthread_mutex_unlock function (this is related to issue 811, but for unmapping rather than destruction). 4. Is it permitted for a thread to lock a mutex in shared memory, unmap it, then later map it again (possibly at a different address) to unlock it? |
|||||||||||
Desired Action |
Provide detailed rules for the storage requirements for process-shared and non-process-shared synchronization objects, possibly under XSH 2.9 Threads, clarifying at least the questions in this issue description and any related questions that arise during discussion. My preference for answers would be: 1. For non-process-shared objects, require they be used at the address at which they were originally initialized. Without this requirement, implementation cost is much higher, and the current approach used by glibc/NPTL on Linux would not be a permissible implementation. 2. I don't have a strong opinion on this issue. Requiring destruction before deallocation does allow some of the cost of self-synchronized destruction (things like issue 811) to be deferred to destruction time instead of imposing it on every 'release' operation, but this only helps if unmapping is also restricted (question 3). If unmapping is not restricted, my weak preference would be not to disallow deallocation without destruction, but to state that failure to destroy before deallocating may result in resource leaks for at least the lifetime of the process. 3. I am undecided on the best course of action, since allowing unmapping imposes a high implementation cost, but my leaning is that unmapping should be permitted in any context where destruction would be valid. Otherwise it's really hard for an application to choose when to unmap certain process-shared objects. Barriers are one of the worst; much of their utility is lost if you need a second synchronization object equivalent to a barrier to synchronize unmapping after returning from the barrier wait. If such unmapping without additional synchronization is disallowed, there should be an application usage recommendation that, when such usage is needed, each thread should make its own mapping of the object, so that it can unmap its own mapping without affecting other threads. 4. Seems like it should clearly be supported for process-shared mutexes, but (by my desired action for question 1) forbidden for non-process-shared ones. |
|||||||||||
Tags | No tags attached. | |||||||||||
Attached Files | ||||||||||||
|
![]() |
||||||
|
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |