[ELDK] Posix Shared Memory

Markus Klotzbücher mk at denx.de
Sat May 24 21:53:30 CEST 2008


"Daniel Stonier" <d.stonier at gmail.com> writes:

> 2008/5/23 Markus Klotzbücher <mk at denx.de>:
>>
>> Hi Detlev,
>>
>> Detlev Zundel <dzu at denx.de> writes:
>>
>> >> "Daniel Stonier" <d.stonier at gmail.com> writes:
>> >>
>> >>> In your experience, is there any reason to favour SYSV over Posix? We
>> >>> only chose posix keeping in mind that we may wish to port to QNX in the
>> >>> future.
>> >>
>> >> Good question. SYSV is a lot heavier than POSIX shared memory and has
>> >> some features that POSIX hasn't (get number of attached processes).
>> >>
>> >> Nevertheless i would choose the POSIX variant because shared memory
>> >> objects are files that can be addressed through the file system instead
>> >> of their own namespace(ftok, ipcs(1) ...)
>> >
>> > The SystemV IPC calls are really going out of use.  The main reason is
>> > that they do not fit into the Unix mind set.  For one, they do not yield
>> > file descriptors that can for example be passed to select (only relevant
>>
>> Yes, agreed.
>>
>> > for message queues).  The other is that they have _persistent_
>> > ressources, like global variables something one should not use
>> > lightheartedly.
>>
>> I think this is true for Posix IPC too, for example sem_overview(7)
>> states:
>>
>>  Persistence
>>       POSIX named semaphores have kernel persistence: if not removed by
>>       sem_unlink(3), a semaphore will exist until the system is shut
>>       down.
>>
>> Same applies to shared mem, the shared memory file in /dev/shm/ exists
>> until shm_unlink'ed.
>
> Yes, I'm finding its somewhat impossible in certain situations to
> ensure that it gets unlinked in all situations. I did think about
> having a monitoring program to keep an eye on them, but we're not
> really finding it essential given that we're only running a few
> processes which *should* be running continuously anyway (so there's
> never any need to free up that shared memory).

Of course with Unix you can always do the following:

1) create shared memory region and have all processes open it.

2) unlink it -> the file will disappear from /dev/shm but it exists
   until all file descriptors are close.

3) use shared memory region and don't bother to close it later.

Best regards

Markus Klotzbücher

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


More information about the eldk mailing list