You can implement a fair queuing system where each thread is added to a queue when it blocks, and the first thread on the queue always gets the resource when it becomes available. Such a “fair” ticket lock built on pthreads primitives might look like this: #include <pthread.h> typedef struct ticket_lock { pthread_cond_t cond; pthread_mutex_t … Read more
Yes. This is a common way to design multithreaded servers and accepted design practice. You can also fork several times and have the child processes call accept, this will allow you to do multithreading without needing a threads library. Older servers do this.
You can use pthread_mutex_trylock. If that succeeds, the mutex was unclaimed and you now own it (so you should release it and return “unheld”, in your case). Otherwise, someone is holding it. I have to stress though that “check to see if a mutex is unclaimed” is a very bad idea. There are inherent race … Read more
Condition variables should be used as a place to wait and be notified. They are not the condition itself and they are not events. The condition is contained in the surrounding programming logic. The typical usage pattern of condition variables is // safely examine the condition, prevent other threads from // altering it pthread_mutex_lock (&lock); … Read more
This does indeed depend on the implementation – so since you have asked about Linux specifically, my comments are refer to the current NPTL implementation of pthreads, which is used in modern glibc. There are two related, but separate, issues here. Firstly, there is this situation: There are read locks currently held, and writers waiting. … Read more
As explained in the openpub documentations, pthread_exit() will exit the thread that calls it. In your case since the main calls it, main thread will terminate whereas your spawned threads will continue to execute. This is mostly used in cases where the main thread is only required to spawn threads and leave the threads to … Read more
The compiler will complain if you don’t cast i to a void pointer: pthread_create(&thread_tid[i], NULL, collector, (void*)i); That said, casting an integer to a pointer isn’t strictly safe: ISO/IEC 9899:201x 6.3.2.3 Pointers An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might … Read more
You can build a FIFO “ticket lock” on top of pthreads mutexes, along these lines: #include <pthread.h> typedef struct ticket_lock { pthread_cond_t cond; pthread_mutex_t mutex; unsigned long queue_head, queue_tail; } ticket_lock_t; #define TICKET_LOCK_INITIALIZER { PTHREAD_COND_INITIALIZER, PTHREAD_MUTEX_INITIALIZER } void ticket_lock(ticket_lock_t *ticket) { unsigned long queue_me; pthread_mutex_lock(&ticket->mutex); queue_me = ticket->queue_tail++; while (queue_me != ticket->queue_head) { pthread_cond_wait(&ticket->cond, &ticket->mutex); … Read more
To be shareable between processes a mutex needs to be initialised accordingly via a properly initialised attribute: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_setpshared.html #include <pthread.h> … pthread_mutex_t * pmutex = NULL; pthread_mutexattr_t attrmutex; /* Initialise attribute to mutex. */ pthread_mutexattr_init(&attrmutex); pthread_mutexattr_setpshared(&attrmutex, PTHREAD_PROCESS_SHARED); /* Allocate memory to pmutex here. */ /* Initialise mutex. */ pthread_mutex_init(pmutex, &attrmutex); /* Use the mutex. */ … Read more
The answer of blaze comes closest, but is not totally clear: conditional variables should only be used to signal a change in a condition. Thread 1 checks a condition. If the condition doesn’t meet, he waits on the condition variable until the condition meets. Because the condition is checked first, he shouldn’t care whether the … Read more