Need help with process synchronization

This is a discussion on Need help with process synchronization within the Linux Programming forums, part of the Platform Specific Boards category; Hello Everyone,
I am trying to write a program on process syncronization using semaphore. The aim is that the parent ...

Need help with process synchronization

Hello Everyone,

I am trying to write a program on process syncronization using semaphore. The aim is that the parent process will print first, then the child will print, then the parent again and so on but it is not working. Please see the code below:

There is a very misleading/ambiguous statement in my linux man sem_init:

Originally Posted by man sem_init

If pshared is nonzero, then the semaphore is shared between processes, and should be located in a region of shared memory (see shm_open(3), mmap(2), and shmget(2)). (Since a child created by fork(2) inherits its parent’s memory mappings, it can also access the semaphore.)

The bold bit is not in the POSIX standard man page:sem_init
It is not false, but it is elliptical (missing further explication). A fork is a copy of the parents memory, addresses remain the same because they are virtual, however, the memory is not automatically shared. But if a copy of an address refers to a shared memory object, then it is the same object in both forks (and this is what the poorly worded bit in parentheses is meant to indicate).

Ie, the idea is that you use shared memory for the semaphore, and both forks receive a copy of an address that can be used to refer to it:

How is writing a file to disk going to represent an improvement? Why bother to do that when it is not necessary? Not to mention what a hassle it creates.

1. SysV shared memory segments are persistent unless deliberately deleted. If the apps are buggy, and exit or crash without destroying the segment, the whole thing leaks. Unless you are a programmer or a sysadmin, you will not think to look for this, or know how to fix it when it happens. With memory mapped files, the memory simply goes away. Yes, you now have a file sitting on disk wasting space, but this is better than wasting memory.

2. A real file in the filesystem is easy to find. You can even open it up in a text editor and see what's going on in there. This is GREAT for debugging.

3. shm uses a separate namespace. Memory mapped files use the same namespace as everything else (i.e., the filesystem).

4. The memory mapped file serves as its own backing store, meaning your shared pages won't use swap space if they get evicted -- they'll just go back to disk again.

5. There is no reason disk activity has to occur, at least until all the instances of the mapping are closed, or if somebody calls msync(). Memory mapped files aren't constantly be synchronized to disk, that would suck infinitely.