Re: [boost] [interprocess] shared memory lifetime

From: Kim Barrett (kab_at_[hidden])
Date: 2006-03-10 18:16:18

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.