sem_init on OS X

Question

I am working on some code which uses the pthread and semaphore libraries. The sem_init function works fine on my Ubuntu machine, but on OS X the sem_init function has absolutely no effect. Is there something wrong with the library or is there a different way of doing it? This is the code I am using to test.

sem_t sem1;
sem_t sem2;
sem_t sem3;
sem_t sem4;
sem_t sem5;
sem_t sem6;

sem_init(&sem1, 1, 1);
sem_init(&sem2, 1, 2);
sem_init(&sem3, 1, 3);
sem_init(&sem4, 1, 4);
sem_init(&sem5, 1, 5);
sem_init(&sem6, 1, 6);

The values appear to be random numbers, and they do not change after the sem_init call.

Solution 1

Unnamed semaphores are not supported, you need to use named semaphores.

To use named semaphores instead of unnamed semaphores, use sem_open instead of sem_init, and use sem_close and sem_unlink instead of sem_destroy.

Solution 2

A better solution (these days) than named semaphores on OS X is Grand Central Dispatch's dispatch_semaphore_t. It works very much like the unnamed POSIX semaphores.

Initialize the semaphore:

#include <dispatch/dispatch.h>
dispatch_semaphore_t semaphore;
semaphore = dispatch_semaphore_create(1); // init with value of 1

Wait & post (signal):

dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
...
dispatch_semaphore_signal(semaphore);

Destroy:

dispatch_release(semaphore);

The header file is well documented and I found it quite easy to use.

Comments

[Adam Rosenfield]

Wow. <semaphore.h> declares sem_init so that it compiles properly on OS X, but it returns -1 with errno set to ENOSYS (function not implemented).

[jcpennypincher]

Ok, now I'm looking for a good example of semaphores using C++ boost libraries. I have heard that is a robust implementation

[user454322]

sem_getvalue() doesn't work either...... See stackoverflow.com/questions/16655153/…

[eonil]

GCD semaphore is GCD level feature. Theoretically, it can cause some issue if combined with pthread level.

[Michael Dorst]

@Eonil can you elaborate? What sort of issues could you have?

[eonil]

@MichaelDorst Wrong question. Basically, you should not use API exposed on different abstraction to control another abstraction unless they are explicitly designed to work together. Even if you know all the details and they are working now because implementation details can change later. If you have no evidence of interoperability, you should assume such usage as unsafe due to potential issues. And there's no evidence that GCD API will work as expected for POSIX thread.

[eonil]

@MichaelDorst Correct question would be "What's the evidence of GCD APIs would work for POSIX thread?" No evidence means unsafe.

[eonil]

@MichaelDorst GCD is not an "extension" or "utility" feature to aid pthread. It's a separated and opaque abstraction that does not depend on implementation details.

[eonil]

@MichaelDorst Just remember that one thread can run multiple GCD queues and a GCD queue can run on any thread except main queue. Stopping a GCD queue doesn't guarantee stopping a POSIX thread. Using GCD API to control POSIX thread is just a non-sense.