Unix Programming - How to properly initialize shared memory on Unix?

Author

How to properly initialize shared memory on Unix?

Andrew S.

2006-08-13, 8:00 am

Hi,

Looks like a newbie question :-) but I've searched a lot on Internet,
and checked quite a lot of books looking for an answer. With no success
yet. I posted this question to programming.threads, but did not get
many responses there.

The question is: suppose there is a shared library which may be loaded
by different processes, and potentially simultaneously. This shared
library needs to create (open) a shared memory region for synchronizing
its operations. How is it possible to ensure that only single process
will create and initialize the shared memory, and the other processes
will only be able to open it after initialization is complete?

Most books/discussions I found assume there is a master process which
is the only one who creates the shared memory object and initializes it
before usage. But even then, suppose the kernel object is created, and
not yet initialized, and a client process opens that kernel object -
how to prevent the client from reading uninitialized data?

One way I thought initially was relying on the shared memory to be
zeroed, but that's not the case on all platforms, as far as I heard.

Another way I'm thinking about right now is to create the initial
structure of smaller size, initialize it with most important staff,
than resize the shared memory (assuming that the new memory after
resizing does not need to be initialized). This way clients will need
to wait until the memory is resized to some larger size from some known
value. Not sure if resizing is portable.

Sincerely,

Andrew

Pascal Bourguignon

2006-08-13, 7:01 pm

"Andrew S." <aschetinin@gmail.com> writes:
> The question is: suppose there is a shared library which may be loaded
> by different processes, and potentially simultaneously. This shared
> library needs to create (open) a shared memory region for synchronizing
> its operations. How is it possible to ensure that only single process
> will create and initialize the shared memory, and the other processes
> will only be able to open it after initialization is complete?

Implementing a mutex, for example, with semaphores. man semget

--
__Pascal Bourguignon__ http://www.informatimago.com/

WARNING: This product warps space and time in its vicinity.

Andrew S.

2006-08-14, 7:00 pm

Pascal Bourguignon wrote:
>
> Implementing a mutex, for example, with semaphores. man semget

The problem with such a mutex (please correct me if I'm wrong) is that
the semaphore-based mutex does not "unlock" in a case when the process
crashes.
This would mean that once the process which locked the mutex crashes,
no other process could access the locked object.

For example, named mutexes in Windows do have such a feature - they
automatically unlock if the process terminates.

Sincerely,

Andrew

Chris Friesen

2006-08-14, 7:00 pm

Andrew S. wrote:

> The question is: suppose there is a shared library which may be loaded
> by different processes, and potentially simultaneously. This shared
> library needs to create (open) a shared memory region for synchronizing
> its operations. How is it possible to ensure that only single process
> will create and initialize the shared memory, and the other processes
> will only be able to open it after initialization is complete?

Have you considered fcntl() locking combined with a flag that indicates
whether the area is in a self-consistent state?

The order of operations would be:

lock
check the flag
if area is not self-consistent
then init as required
else
clear consistency flag
do operations
set consistency flag
unlock

If the app dies in the middle of writing, then the lock is automatically
freed, and the next user will know that it needs to do the initialization.

Chris

Andrew S.

2006-08-15, 4:00 am

Chris Friesen wrote:
>
> Have you considered fcntl() locking combined with a flag that indicates
> whether the area is in a self-consistent state?
>
> The order of operations would be:
>
> lock
> check the flag
> if area is not self-consistent
> then init as required
> else
> clear consistency flag
> do operations
> set consistency flag
> unlock

Well, I did not :-) thanks for advice.
This could work wery well with SystemV shared memory which is zeroed on
creation.
POSIX shared memory is not guaranteed to be zeroed (while most modern
platforms most probably clear the memory, some older platforms and may
be real-time platforms skip it for efficiency), and therefore a
consistancy flag is problematic to rely on.
But if fcntl works with SystemV shared memory descriptors (I'll check
it right away), that could work perfectly.

Thanks!

Andrew

Nils O. Selåsdal

2006-08-15, 4:00 am

Andrew S. wrote:
> Pascal Bourguignon wrote:
>
> The problem with such a mutex (please correct me if I'm wrong) is that
> the semaphore-based mutex does not "unlock" in a case when the process
> crashes.
sysv semaphores has the SEM_UNDO flag, which can be used to "undo" an
operation when the process exits (such as in a crash).

Last I tried, which granted, was about two years ago, code
from R.Stevens UNP book did not work reliably on linux regarding
SEM_UNDO though.

Andrew S.

2006-08-15, 4:00 am

Nils O. Sel=E5sdal wrote:

> sysv semaphores has the SEM_UNDO flag, which can be used to "undo" an
> operation when the process exits (such as in a crash).
>
> Last I tried, which granted, was about two years ago, code
> from R.Stevens UNP book did not work reliably on linux regarding
> SEM_UNDO though.

Thanks, Nils, that's very interesting. I've read about this SEM_UNDO
flag recently, and was interested in trying it out, but if it is
unreliable... :-)

Sincerely,

Andrew

Andrew S.

2006-08-20, 8:00 am

Andrew S. wrote:
> Nils O. Sel=E5sdal wrote:
>
>
> Thanks, Nils, that's very interesting. I've read about this SEM_UNDO
> flag recently, and was interested in trying it out, but if it is
> unreliable... :-)
>
> Sincerely,
>
> Andrew

BTW, ACE library seems to employ an improved variant of Stevens's
technique.

Andrew

Sponsored Links