Comments on: Semaphores on Linux – sem_init() vs sem_open()

By: Debugging python-for-android with gdb — /dev/blah

Debugging python-for-android with gdb — /dev/blah — Tue, 13 Nov 2012 01:11:16 +0000

[...] been sinking a lot of time in trying to make python-for-android support multiprocessing, and for various reasons, it turns out to be a bad idea®, but in doing that, i had to go to great extents to [...]

By: Pat Patterson

Pat Patterson — Mon, 27 Feb 2012 16:12:10 +0000

abhishek – sem_open is mentioned towards the bottom of the blog entry as a simpler alternative to sem_init. See also Vikram’s original article: http://linuxdevcenter.com/pub/a/linux/2007/05/24/semaphores-in-linux.html?page=4

By: abhishek

abhishek — Mon, 27 Feb 2012 04:36:18 +0000

So what part of this article explains sem_open???? I came looking for some explanation on named semaphores but found the easy unnamed semaphores instead

By: Pat Patterson

Pat Patterson — Sat, 14 Jan 2012 00:56:59 +0000

Hi zac – sem_open() takes the semaphore name, so you should be able to use that, I think.

By: zac

zac — Wed, 11 Jan 2012 16:05:22 +0000

I forgot to mention i am coding in C.
Tnx a bunch!

By: zac

zac — Wed, 11 Jan 2012 16:01:35 +0000

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?

By: Vikraman

Vikraman — Wed, 17 Aug 2011 11:35:24 +0000

Thank you, this literally saved my day

By: Pat Patterson

Pat Patterson — Fri, 29 Jul 2011 00:42:38 +0000

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?

BTW – it’s better to create a gist and post the URL here – then your code won’t get eaten by WordPress – https://gist.github.com/

By: Nilesh

Nilesh — Thu, 28 Jul 2011 19:51:36 +0000

Thanks for this explanation. I tried using sem_open this way:

if ((mutex = sem_open(“mysemaphore”, O_CREAT, 0644, 0)) == SEM_FAILED) {
cerr << "semaphore initilization error" << endl;
return 1;
}

pid_t pid = fork();

if (0 == pid) {
/*
if ((mutex = sem_open("mysemaphore", 0, 0644, 0)) == SEM_FAILED) {
cerr << "semaphore initilization error" << endl;
return 1;
}
*/
cout << "here1" < 0) {
sem_wait(mutex);
cout << "here2" << endl;
wait(&retval);
}

The output is:
here2
here1

that's not correct. Am I missing something?

By: Pat Patterson

Pat Patterson — Fri, 01 Apr 2011 04:19:43 +0000

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.