The standard mechanism for this is the semaphore. I won't get into a deep discussion of semaphores here, the Wikipedia article linked in the preceding sentence gives a good description. Basically, if you want to ensure that no more than one thread (ok, 'n' threads in the general case) has access to some resource concurrently, you use a semaphore.

Looking for an example of semaphores on Linux, I found the aptly named Semaphores in Linux, by Vikram Shukla, on the O'Reilly Linux DevCenter. This is a very useful article, explaining the general semaphore concept and comparing the System V and POSIX semaphore implementations.

Guided by the article, in particular, the 'Related Process' example, which closely matched my use case, I wrote a quick test program using the POSIX sem_init() call to initialize a semaphore and sem_wait()/sem_post() to decrement/increment the semaphore respectively. Only one problem. It didn't work - my processes had concurrent access to the shared resource!

Going back to Vikram's example, and reading the sem_init() man page very carefully, the issue seems to be that the semaphore is created on the stack of the parent process. When the child is forked, it gets a copy of the semaphore, not a reference to the parent's semaphore. Adding a few sleep()'s and printf()'s to the example highlights the problem:

If pshared is non-zero, 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.) Any process that can access the shared memory region can operate on the semaphore using sem_post(3), sem_wait(3), etc.

The key here is that the semaphore must be in a region of shared memory, even if you're accessing it from related processes such as a parent and its child.

There are two ways of fixing the problem. The first is to use shm_open(), ftruncate() and mmap() to create a shared memory region and obtain a pointer to it:

Postscript: this is a minor flaw in an otherwise excellent and very useful article. I address it here, rather than in a comment on the article, due to the amount of space required for a full explanation.

One question is ..even if you share the memory and get the shm descriptor for shared memory how will you pass on to other unrelated processes (processes which are not related by parent child relationship)…

What I think of is message queues of System IPC would work…correct me if i am wrong…

Hi Nisheeth – shm_open takes a name for the shared memory region, so unrelated processes just need to know the same name. Yes – I think System V IPC message queues can do all this, they just looked quite a bit more complex to deal with when I was working on this.

Hi Nilesh, it looks like your code is missing a couple of lines, but I think I understand your question. The answer is that the order in which the two processes enter the critical section is not guaranteed; only the fact that they won’t be there at the same time. What are you trying to do?

Dear Pat,thank u 4 that wonderful post.
Cud you plz suggest something 4 thhis problem i am facing:
I am testing a custom inter-process semaphore implementation where semaphore is called as a function, ie, one function to create sem,another function to take sem and so on.
I am forking a process and i want the sem to be created in the shared memory.
I cannot pass the sem_t *sem value to the custom function(it has only one argument,which is semaphore name).
What can i do to make this function run in the shared memory space?Or how can i get around this problem?

/* In this braindamaged version of placeWidget, the widget builders don’t
coordinate at all, and merely print a random pattern. You should replace
this code with something that fully follows the p3 specification. */
void placeWidget(int n)
{
CHK(sem_wait(sem));