Defect report from : Ulrich Drepper , Red Hat, Inc.
(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
@ page 786 line 25802 section mmap() comment {ud-shared-sync}
Problem:
Edition of Specification (Year): 2004
Defect code : 3. Clarification required
[I attach this report to mmap and this might be where an explanation can be
placed, but it applies to the pthread sync primitives.]
Consider a process which create a file, mmap()s it with MAP_SHARED, and
in the shared memory region creates a pthread_mutex_t object with the
pshared attribute set (i.e., pthread_mutexattr_setpshared used).
This is supposed to work and other processes can just map the file and
use the shared mutex.
But what happens if all processes, which have the shared memory region
mapped, either terminate or unmap the memory. If this happened, will
another process then be able to open the file and use the shared mutex
right away without initialization?
I'm torn between answering yes and no. On the plus side, this would
allow having persistent sync primitives. The mutex, in this case, could
be associated with a file and whenever somebody uses the file content
the mutex has to be locked. There are no races in the re-initialization
of the mutex.
On the other side, an implementation might chose to add the necessary
magic needed for the shared sync primitive to the actual shared memory
region. Once all processes unmapped the shared memory region the
attributes are gone.
The latter would be good for implementations, the former for
applications. What shall it be?
Action:
If we can agree on a behavior, I'll file a follow-on bug with specific wording.
If we cannot agree on a behavior, explicitly state that this is undefined by
adding perhaps a new paragraph after line 25808:
The state of synchronization objects such as mutexes, semaphores, barriers,
conditional variables placed in shared memory mapped with MAP_SHARED becomes
undefined if the last descriptor of the underlying file has been closed.
|