shared memory

[baesik]

I am trying to use shared memory to pass information between processes.
I see there are two ways (are there more??) to this.

one is to use shared memory using shmget(), shmat(), etc and another is
to use mmap (without actual file) using shm_open() and mmap().

are there any advantages of using one over the other?

also I noticed if the process fails to clean up and terminates (ie,
either due to crash or bad code), the shared resources are not cleaned
up by OS. Is there anyway, I can set so the shared resources gets
cleanup by OS when processes which were using them terminate?

Thanks.

[Kasper Dupont]

baesik wrote:
>
> I am trying to use shared memory to pass information between processes.
> I see there are two ways (are there more??) to this.

I have written a bit about it in the FAQ (not much):
http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html#shm_open

>
> one is to use shared memory using shmget(), shmat(), etc and another is
> to use mmap (without actual file) using shm_open() and mmap().
>
> are there any advantages of using one over the other?

There might be platforms implementing only one of the two.

>
> also I noticed if the process fails to clean up and terminates (ie,
> either due to crash or bad code), the shared resources are not cleaned
> up by OS. Is there anyway, I can set so the shared resources gets
> cleanup by OS when processes which were using them terminate?

With SysV shared memory, I have usually used the shmctl
function to delete the shared memory segment right after
calling shmat. Some people says that is not supposed to
work, but it does work. And since it is AFAIK the only
way to prevent leaks, I think it is a good idea to do it.

With Posix shared memeory, I think you can do something
similar by calling shm_unlink right after shm_open. You
will not be able to access the same segment by calling
shm_open again, but the already opened fd can be mmaped
by multiple processes.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaa...@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

[martin]

baesik <bae...@yahoo.com> wrote in message news:<3E543F39...@yahoo.com>...

Are the communicating processes started from a single parent? Than
this process could create a anonymous file with tmpfile(3) and every
child mmap this inherited filedescriptor as shared memory. If the
last of this group of processes terminates, everything is cleaned up.

martin

[Vishal Augustine]

One way to clear the shared resource when the program crashes, is to include the "clearing method" in the signal handler. The "clearing method" is upto you ... You can delete the shared resource (Be careful, maybe the other process is accessing it) or you can just reset the values (But again, you may need to use semaphores to make sure only one process is writing to the location).

The signal handler will ensure that the code will exit (even if it is a crash) only after cleaning the location. But again SIGKILL (siganl 9) and SIGSTOP can not be trapped.

Regards
Vishal

-- 
----------------------------------------------------------------------
When in doubt, follow your heart.
----------------------------------------------------------------------

 

[Roger Leigh]

baesik <bae...@yahoo.com> writes:

> one is to use shared memory using shmget(), shmat(), etc and another is
> to use mmap (without actual file) using shm_open() and mmap().

shm_open/mmap do use "actual files". They are created under /dev/shm
(which should be a tmpfs (shmfs) filesystem).

> are there any advantages of using one over the other?
>
> also I noticed if the process fails to clean up and terminates (ie,
> either due to crash or bad code), the shared resources are not cleaned
> up by OS. Is there anyway, I can set so the shared resources gets
> cleanup by OS when processes which were using them terminate?

If you use shm_open, then shm_unlink will unlink the file under
/dev/shm, and when you close the fd (e.g. when the program
terminated), all the disk blocks in use will be freed, just like a
normal file--much more elegant than shmget() et. al., since it uses
the normal filesystem and isn't subject to shared memory segments
leaking (provided you use shm_unlink).

OTOH, SYSV shm is much more widely available than POSIX shm, which is
only supported by Linux 2.4.x, and not at all by many commercial UNIX
systems.

--
Roger Leigh

Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers