Austin Group Bug Tracker
2014-08-08 23:03:14 UTC
The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=864
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 864
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Rich Felker
Organization: musl libc
User Reference:
Section: unknown
Page Number: unknown
Line Number: unknown
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-08 23:03 UTC
Last Modified: 2014-08-08 23:03 UTC
======================================================================
Summary: 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.
======================================================================
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
======================================================================
======================================================================
http://austingroupbugs.net/view.php?id=864
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 864
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Rich Felker
Organization: musl libc
User Reference:
Section: unknown
Page Number: unknown
Line Number: unknown
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-08 23:03 UTC
Last Modified: 2014-08-08 23:03 UTC
======================================================================
Summary: 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.
======================================================================
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
======================================================================