Boost logo

Boost Users :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-03-19 04:48:42


Boris wrote:
> On Tue, 18 Mar 2008 21:23:39 +0100, Ion Gaztañaga <igaztanaga_at_[hidden]>
> wrote:
>
>> Boris wrote:
>>> If I instantiate a shared_memory_object with open_or_create how do I
>>> know
>>> if it was opened or created? I ask as if it was created I need to
>>> create a
>>> structure in the mapped region. If it was opened though I must not
>>> create
>>> a structure (as another program created the structure before and I might
>>> overwrite data).
>>>
>>> I ran into this problem after creating a reader and writer. They
>>> exchange
>>> data using a shared_memory_object. It would be great if I could start
>>> the
>>> two programs in any order. But currently the programs don't know which
>>> one
>>> created and which one opened the shared memory. Do I miss anything or
>>> was
>>> open_or_create added for another use case?
>>>
>>> Boris
>> Since you must create an object to share between both, use
>> find_or_construct<> on both processes (supposing both have enough
>> information to create the shared structure) before doing anything. If
>> the object is already created, the function will return a pointer to the
>> already created structure.
>
> Can I use find_or_construct<> also with the shared_memory_object? It seems
> like I must use managed memory segments then?

Yes. Underlying OS shared memory devices shm_open or similar have no way
to tell you if you've created or open the device. Another alternative is
to start creating and opening exclusively in a loop. In most cases you
won't need to loop more than two times to open or create it with
different calls.

Imagine you start the server first. Even if I could add a mechanism to
shared_memory_object had to tell if you've opened or created it, the
client can open it just after the server has created it and the client
must wait until the server. So you need some sort of synchronization
even if you know who created the segment.

Regards,

Ion


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net