Thread: Need help with process synchronization

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:

Code:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <semaphore.h>
#include <sys/mman.h>
#include <fcntl.h>

typedef struct {
	sem_t one;
	sem_t two;
} SemPair;

int main(int argc, const char *argv[]) {
	int shm = shm_open("/test", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
	ftruncate(shm, sizeof(sem_t));
	SemPair *sem = mmap(NULL, sizeof(sem_t), PROT_READ | PROT_WRITE, MAP_SHARED, shm, 0);

	sem_init(&(sem->one), 1, 0);
	sem_init(&(sem->two), 1, 0);

	pid_t pid = fork();
	if (!pid) {
		while (1) {
			sem_wait(&(sem->two));
			fprintf(stderr,"Child %d\n", getpid());
			sem_post(&(sem->one));
		}
	} else {
		while (1) {
			sem_post(&(sem->two));
			sem_wait(&(sem->one));
			fprintf(stderr,"Parent %d\n", getpid());
			sleep(1); /* regulate both processes */
		}
	}
	return 0;
}

This does a perfect:

root~/C»./a.out
Child 4880
Parent 4879
Child 4880
Parent 4879
Child 4880
Parent 4879
Child 4880
Parent 4879
[...]


However, if you change the first three lines of main() to:

Code:

	SemPair *sem = malloc(sizeof(*sem));

The whole thing fails, because the semaphore is not shared between the processes.

Code:

while (pointNotYetMade())
    Use mmap()'d files for shared memory between processes, not shm!

Originally Posted by brewbuck

Code:

while (pointNotYetMade())
    Use mmap()'d files for shared memory between processes, not shm!

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.

I've actually never used these semaphores (POSIX:SEM) before; I've just used POSIX:XSI between threads and not processes.

Anyway, I notice that the shared mem issue can be resolved by using sem_open() to get an address rather than creating the type and using sem_init().

Code:

#include <semaphore.h>
#include <sys/mman.h>
#include <fcntl.h>

typedef struct {
	sem_t *one;
	sem_t *two;
} SemPair;

int main(int argc, const char *argv[]) {
	SemPair sem;
	sem.one = sem_open("/test1", O_CREAT, S_IRUSR | S_IWUSR, 0);
	sem.two = sem_open("/test2", O_CREAT, S_IRUSR | S_IWUSR, 0);

	pid_t pid = fork();
	if (!pid) {
		while (1) {
			sem_wait(sem.two);
			fprintf(stderr,"Child %d\n", getpid());
			sem_post(sem.one);
		}
	} else {
		while (1) {
			sem_post(sem.two);
			sem_wait(sem.one);
			fprintf(stderr,"Parent %d\n", getpid());
			sleep(1); /* regulate both processes */
		}
	}
	return 0;
}

Originally Posted by MK27

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.