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
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

- Relationships
related to 0000972Closedajosey PTHREAD_PROCESS_PRIVATE: definition too weak to allow for optimization 

-  Notes
(0002389)
martinr (reporter)
2014-09-16 18:42
edited on: 2014-09-16 18:43

 Solaris uses kernel mutex when pthread_mutex_t is initialized with
PTHREAD_PROCESS_SHARED attribute. Also mutex becomes a shared-between-processes
when the mutex is initialized with PTHREAD_MUTEX_ROBUST attribute. In both
cases there exist a linked list of pointers referring to pthread_mutex_t
structures in the address space of the process. Let's call this type B.

On the other hand if we have neither PTHREAD_PROCESS_SHARED or
PTHREAD_MUTEX_ROBUST mutex the is no reference to pthread_mutex_t in the
address space and all the locking related functionality happens in the user
space. Let's call it type A.

All the pthread library mutex related locking features on Solaris derive from this.

Here you can find answers for questions found in 'Desired Action'. Generally I
didn't find a word about any of the questions in the documentation which means
the result is undefined.

1. It will work.

2. Generally you can't deallocate without destroy type B. For type A you can do
it in case there is no risk of dead lock (multiple cases).

3.1 Should work.
3.2 Should work.
3.3 Generally it will not work.

4. It will work just for type A.
(0002543)
dalias (reporter)
2015-02-09 22:44

 The remarks for question 3 in note 0002389 seem to be based on an interpretation of it as containing three independent parts/subquestions. The (1)-(3) in the example were not intended this way but as multiple simultaneous conditions that could occur and which an implementation might need to address if the answer is yes.
(0005911)
geoffclare (manager)
2022-07-25 16:14

 This was discussed in the July 25, 2022 teleconference. We believe that items 1 and 4 may have already been addressed by the addition of XSH 2.9.9 in TC2. Items 2 and 3 could perhaps be dealt with by adding more text to that section, but we need proposed wording.
(0006427)
Don Cragun (manager)
2023-08-10 15:41

 This was discussed again in the August 10, 2023 teleconference. Items 2 and 3 could perhaps be dealt with by adding more text to that section, but we still need proposed wording.

- Issue History
Date Modified Username Field Change
2014-08-08 23:03 dalias New Issue
2014-08-08 23:03 dalias Name => Rich Felker
2014-08-08 23:03 dalias Organization => musl libc
2014-08-08 23:03 dalias Section => unknown
2014-08-08 23:03 dalias Page Number => unknown
2014-08-08 23:03 dalias Line Number => unknown
2014-09-16 18:42 martinr Note Added: 0002389
2014-09-16 18:42 martinr Note Edited: 0002389
2014-09-16 18:43 martinr Note Edited: 0002389
2014-09-16 18:43 martinr Note Edited: 0002389
2014-09-16 18:43 martinr Note Edited: 0002389
2015-02-09 22:44 dalias Note Added: 0002543
2015-05-07 08:23 dancol Issue Monitored: dancol
2022-07-25 16:14 geoffclare Note Added: 0005911
2022-07-25 16:15 geoffclare Relationship added related to 0000972
2023-08-10 15:41 Don Cragun Note Added: 0006427

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