在没有互斥锁的情况下立即唤醒所有线程

Question

My program processes database rows in different threads depending on one of the row's fields. The main thread spawns off the "workers", performs a query, and then, for each row, needs to wake up all of the workers for one of them to consume the row.

Now, using pthread_cond_broadcast() seems like the most logical choice. However, the workers in this case must all wait inside pthread_cond_wait() using the same mutex .

In my case this is suboptimal, because it means, the workers will be woken up one at a time (which I do not need) -- instead of all at once . Yes, I do want them all to wake up -- they would all read one field from the new DB-row, after which all but one will go back to waiting for the next row. I do not need to synchronize them.

I thought, I'd use a dummy thread-specific mutex with the pthread_cond_wait() in each thread, but that is not working (only one thread is woken up). The standard says, waiting for the same condition variable using different mutexes (as I do) is undefined.

So, is there a way to notify all threads at once ? Thanks!

Answer 1

I think you need to describe more about the problem and why you're (attempting) to do it this way to begin with. I wouldn't be surprised if the best way is to do something completely different that doesn't involve waking up all threads at once without a mutex.

To me, your description sounds like:

• Main thread spawns several threads (where spawning a thread is relatively expensive)
• Main thread does a query, while the spawned threads start, do very little, then block (where starting/restarting and blocking are relatively expensive)
• For each row the main thread wakes up every thread (relatively expensive restarting and blocking) and every thread except one of them goes back to waiting (very wasteful)

Without knowing why you're doing any of this, I'd assume that not using any threads at all would be faster (eg that the main thread would be able to process a row faster than the main thread can examine the row and tell one spawned thread to process it and hassle other threads for no reason).

If processing a row takes a long time, then I'd consider having worker threads waiting on a FIFO queue, such that the main thread pushes a "process this row" command onto the queue and the first thread that grabs it from the queue processes that row.

Of course I have no idea why you want to do what you want to do, and therefore any suggestion is just a guess.

TL;DR: I think your question is a bit like someone that wants to lose weight asking "what is the best way to chop off my own legs" (where the most practical answer has nothing to do with the question actually asked).

Answer 2

With condition variables, the assumption is that there is some associated "condition" (the data row in your case) that needs to be checked and updated exclusively (hence the mutex). Whichever other mechanism you choose, you will need to figure out how to ensure exclusive access to your "work queue" (whether it's a single slot or a real queue).

With a shared queue, you will always have 2 writers (main thread + intended worker) and N-1 readers to the data structure. You could use read-write locks (rwlock) to ensure integrity.

Alternatively you could have N separate queues (one per worker). You would push a copy of the data row to each worker.

As far as waking up several threads at once: you could have your workers "sleep" (eg with select()) and wake them up with pthread_signal() (in a loop).

You could also use pthread_barrier_wait() .

The pthread_barrier_wait() function shall synchronize participating threads at the barrier referenced by barrier. The calling thread shall block until the required number of threads have called pthread_barrier_wait() specifying the barrier.

When the required number of threads have called pthread_barrier_wait() specifying the barrier, the constant PTHREAD_BARRIER_SERIAL_THREAD shall be returned to one unspecified thread and zero shall be returned to each of the remaining threads. At this point, the barrier shall be reset to the state it had as a result of the most recent pthread_barrier_init() function that referenced it.

1. initialize the barrier with pthread_barrier_init() (with count = 1 + # of workers)
2. in each worker, call pthread_barrier_wait() in a loop; when that returns, new data is ready
3. in the main thread, call pthread_barrier_wait() to signal the workers

Unfortunately (as the OP notes), in the next iteration, no worker will be woken up until the previously activated worker finishes its job.

A simpler architecture would have the main thread dispatch events to the proper worker (instead of waking all workers up and having them figure out which one is the intended recipient). Unless you have as many cores as workers, the tests will not really happen in parallel anyway. Also, even if you have enough cores to let the workers run in parallel, N-1 of them will not learn that the "winner" has taken up the job before they finish testing, so the total amount of work across all cores is higher.