Re: [boost] [interprocess] shared memory lifetime

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-03-10 15:25:09

Hi Kim,

> First let me make sure I understand what is going on here.
> 
> On Windows, the shmem library is presently using create_file_mapping
> and open_file_mapping, while on POSIX systems it is using shm_open.

Right.

> An object created with create_file_mapping exists until there are no
> references, assuming I'm understanding what you've said. (I don't
> have (easy) access to Windows API documentation, so can't go look up
> this information. Please correct me if you see any confusion.)

You can use MSDN (www.msdn.com)

> A POSIX shared memory object exists from the time it is created until
> it is unlinked and all references are gone (or the system is
> rebooted). (It becomes inaccessible to further shm_open calls if
> unlinked, but remains open to processes that had already opened it.)

Right. The difference is that in windows, if there's still a process 
connected to the shared memory, another process can open the same 
segment. If a UNIX process calls shm_unlink, them the processes that 
opened the shared memory can still work on it, but if another process 
can't use that memory, because the name is removed. From OpenGroup site:

http://www.opengroup.org/onlinepubs/007908799/xsh/shm_unlink.html

"The shm_unlink() function removes the name of the shared memory object 
named by the string pointed to by name. If one or more references to the 
shared memory object exist when the object is unlinked, the name is 
removed before shm_unlink() returns, but the removal of the memory 
object contents is postponed until all open and map references to the 
shared memory object have been removed."

So if a process calls shm_unlink another process can create new shared 
memory segment with the same name, but never connect to that old shared 
memory. This is different from a file unlink behavior, I think.

> What the present library implementation is trying to do with this
> reference count mechanism is to emulate the Windows behavior on POSIX
> systems. 

Right. I find windows behaviour easier to implement with posix (when 
there is no crash) than emulating posix with windows.

> Unfortunately, as has been noted, that emulation really isn't
> very reliable in the face of ill-behaved (i.e. crashing) clients. And
> I'm pretty sure there isn't a solution to that problem, at least not
> with the shm_open &etc API.

I'm sure there is a solution. But every implementation I've checked 
(apache for example) doesn't solve this. Last time I checked Apache 
portable runtime tries emulates posix-like behavior but shm_unlink in 
windows in empty.

One option is to use a memory mapped file to emulate posix-like behavior 
in windows. But it surely will be slower (the OS will dump data to file) 
and the unlink is not trivial.

> First question: Why not use the shm_open interface on Windows? One
> possible answer would be that the Windows POSIX support doesn't
> include the shm_xxx API. And that might even be the answer, since
> some web searches have led me to suspect that Windows only supports
> the SysV shared memory API. Which leads to

Windows natively does not support posix nor System V. I think that with 
Unix Services for Windows (previously Interix)you have system V 
interface. I think Unix Services for Unix is a free download now, but I 
think you need to use that environment to build a Unix-like application 
(using gcc compiler). I don't know if those system V functions are 
available with a normal windows environment.

> Of course, we have yet to have the discussion of which behavior is
> actually preferable. But it is certainly the case that the present
> situation, where the behavior is not documented and is buggy on
> non-Windows platforms, is not ideal.

I'm not happy with the behavior of the shared memory. For a not 
reference-counted implementation you can use memory mapped files. I 
don't know if this will be slower, though.

Ion