Programming

I am attempting to write a program with multiple POSIX threads. I want to ensure all threads are released at the same time. I am (trying to) use a semaphore to accomplish this.

Without too much irrelevant information, I declare my semaphore with 0 of 25 resources available. Is there a way to instantly make all resources available? It seems the only way to make a resource available is with sem_post(&semaphore_name), but that only makes one available.

I would like to make all 25 available at once so my threads all become unblocked at once and run concurrently.

Any suggestions?

Thank you!

Unfortunately sem_post doesn't support multiple posts at once. SYSV IPC sems do, I believe, but they may have higher overhead. You might also check out 'man pthread_cond_init'. A condition variable isn't quite a semaphore, but does support launching multiple threads with one signal.

Hello Snowbarr,

Well, it's a tradition in POSIX threads to avoid semaphores whenever possible ... Corona688 idea to use condition variables (with a broadcast) is a good, see man pthread_cond_broadcast() and pthread_cond_wait() among others,

Another possibility, that may even better fit, could be using a barrier: see man pthread_barrier_init() and pthread_barrier_wait().

HTH,
Loïc

Humm, not quite so. Remember condition variables have an associated mutex. Only one thread is actually unblocked. If pthread_cond_signal() is used and several threads are blocked the thread that is actually signaled and acquires the associated mutex is determined by the scheduling policy. If pthread_cond_broadcast() is used all threads that are blocked are notified but still, at the end of the day, only one thread can acquire the mutex and proceed.

A better approach might be to use Pthread barriers.

I stand corrected, thank you.
How come?

The pthread_cond_broadcast() function shall unblock all threads currently blocked on the specified condition variable cond.

opengroup /functions/pthread_cond_signal.html

yes, we don't use semaphores.

Well, this is a joke coming from the comp.programming.threads NG.

The reason behind this joke is: in most of the cases, POSIX threads offers synchronization mechanisms that surpass what semaphores can offer. For instance, a mutex could be seen as a binary semaphore. But mutex is more efficient in the uncontended case (indeed, there is no kernel involvement. This is not the case for semaphore). Beside that, mutex can offer priority inheritance, something impossible with semaphore.

From my own experience, most of the time where semaphores are used in Pthreads program often results from a lack of Pthreads understanding. There are only very few specific cases where semaphores make more sense.

Cheers,
Loïc.