A different way to address this problem is primarily through documentation. One change to the library interface is also needed, the addition of an explicit deletion/unlink operation. And eliminate the reference counting mechanism from the POSIX port. Here is some proposed text, offered as an option for discussion. Portability Issue for Shared Memory Lifetime The lifetime of a shared memory object varies depending on the platform. On Windows platforms, a shared memory object exists from the time it is created until the last reference to it is removed. For POSIX platforms, a shared memory object exists from the time it is created until it is deleted and the last reference to it is removed; once deleted, no new references can be created. This is a portability issue which unfortunately shows through the library interface. Various methods for eliminating the difference were explored, but none were found to be both satisfactory and robust. As a result of this difference in the lifetime behavior, systems which are intended to be portable across different platforms need to take special care in the design of the lifetime management of shared memory objects. Some recommendations include - For each shared memory object, identify a single process as its owner, and assign it responsibility for creating the shared memory object, deleting any existing object if present, and ensuring that the new object remains accessible for as long as necessary. This may require putting the process into a sleep loop, to ensure that if the system is running on a Windows platform that the reference count will remain positive. Forced deletion by the creator process ensures that a zombie left over from a previous execution of the system will not be reused. - Avoid the use of the create_or_open interfaces provided by this library. This is really a corollary of the previous item. The problem is that on a POSIX system there is no way to use such an operation correctly, because there is no way to distinguish between a properly existing shared memory object that should be opened, and a zombie from a previous execution of the system that should be deleted and re-created. Those interfaces provide access to operating system facilities, so it was deemed desirable to have them present in the library, but their use in portable code is problematic. - Don't assume that explicit deletion of a shared memory object will actually make it inaccessible to future operations. For example, on Windows the explicit deletion operation does nothing, and a shared memory object is only removed when there are no longer any references to it.