65

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.

Nippysaurus
  • 20,110
  • 21
  • 77
  • 129

3 Answers3

101

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.

Dan Moulding
  • 211,373
  • 23
  • 97
  • 98
Nippysaurus
  • 20,110
  • 21
  • 77
  • 129
  • 50
    Wow. `` declares `sem_init` so that it compiles properly on OS X, but it returns -1 with `errno` set to `ENOSYS` (function not implemented). – Adam Rosenfield Jun 04 '11 at 04:04
  • Ok, now I'm looking for a good example of semaphores using C++ boost libraries. I have heard that is a robust implementation – jcpennypincher Aug 06 '11 at 07:00
  • `sem_getvalue()` doesn't work either...... See http://stackoverflow.com/questions/16655153/sem-getvalue-dysfunctionality-in-mac-os-x-c/16655541#16655541 – user454322 May 28 '14 at 10:10
25

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.

Jess Bowers
  • 2,846
  • 1
  • 22
  • 42
  • GCD semaphore is GCD level feature. Theoretically, it can cause some issue if combined with pthread level. – eonil Dec 24 '16 at 17:31
  • @Eonil can you elaborate? What sort of issues could you have? – Michael Dorst Mar 29 '19 at 17:28
  • 2
    @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 Apr 04 '19 at 16:32
  • @MichaelDorst Correct question would be "What's the evidence of GCD APIs would work for POSIX thread?" No evidence means unsafe. – eonil Apr 04 '19 at 16:36
  • @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 Apr 04 '19 at 16:39
  • @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. – eonil Apr 04 '19 at 16:50
0

If you look at the implementation of sem_init in the source then it just returns an error, while some of the other bsd fns like sem_open still have implementation.

Both the "deprecated" posix fns and libdispatch/GCD call from userspace using fns like semphore_create and semaphore_wait. You can use these directly if you want an old-style sema that always uses the kernel/OS, but you're better with ones like from GCD that uses atomic counters internally and only calls the kernel/OS if it has to wait.

https://github.com/apple/darwin-xnu/blob/a1babec6b135d1f35b2590a1990af3c5c5393479/bsd/kern/posix_sem.c

G Huxley
  • 1,130
  • 14
  • 19