IEEE Standards Interpretation for IEEE Std 1003.1™-2001 IEEE Standard Standard for Information Technology -- Portable Operating System Interface (POSIX®)
Copyright © 2006 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.
Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.
IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA
Interpretation Request #79
Topic: mmap() shared synchronization primitive Relevant Sections: XSH mmap() Page: 786 Line: 25802
Consider a process which creates 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?
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.
Interpretation Response #79
The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.
Rationale for Interpretation
The working group agreed that the behavior is undefined.