使用信号量的for循环在进程之间进行同步

Question

Context:

• I am trying to have two processes writing to the same array in the shared memory space.

• Each process will write half of the array with a for loop.

• The first element of the array will always store the index of the next element to be written.

• IPC is done through a semaphore in the shared memory.

Preconditions:

1. Both the array and semaphore are properly set up in the shared memory.
2. The programme works fine if I wait sem_wait and sem_post outside of the for loop, meaning make the whole process atomic. (This is also the reason why I believe the semaphore and array has been set up properly)

Problem

However, when I try to reduce the critical region by putting sem_wait and sem_post into the for loop. It is not sync as there are part of the array which are not written. But the two processes finished their loops where the total loop counts should be equal to the array length.

Many thanks to suggestions why this happens???

---

UPDATE

On OS X, sem_init() is not working as expected. Used sem_open() to solve the problem. Reference: http://lists.apple.com/archives/darwin-dev//2008/Oct/msg00044.html

Answer 1

In psuedo code for problem case, the parent thread requires semaphore as soon as it is released by itself. Now since, the semaphore is available, parent will go on executing. When its time slice expires, the kernel may switch to child process, but it is waiting for semaphore. The semaphore is acquired by parent process. So again parent will continue to execute.

In this scenario, parent executed twice and child did not execute.

This might have resulted in out of sync execution.

Answer 2

Looking at your actual code I think the problem is with how you are creating your semaphore. If you read the man page on 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.) Any process that can access the shared memory region can operate on the semaphore using sem_post(3), sem_wait(3), and so on.

The key here is the text in bold - your semaphore isn't in shared memory so it's not really shared between the two processes hence the contention you are seeing.