Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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).</p> <p>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.</p> <p>Alternatively you could have N separate queues (one per worker). You would push a copy of the data row to each worker.</p> <p>As far as waking up several threads at once: you could have your workers "sleep" (e.g. with select()) and wake them up with pthread_signal() (in a loop).</p> <p>You could also use <a href="http://pubs.opengroup.org/onlinepubs/009695299/functions/pthread_barrier_wait.html" rel="nofollow">pthread_barrier_wait()</a>.</p> <blockquote> <p>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.</p> <p>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.</p> </blockquote> <ol> <li>initialize the barrier with <a href="http://pubs.opengroup.org/onlinepubs/009695299/functions/pthread_barrier_init.html" rel="nofollow">pthread_barrier_init()</a> (with count = 1 + # of workers)</li> <li>in each worker, call pthread_barrier_wait() in a loop; when that returns, new data is ready</li> <li>in the main thread, call pthread_barrier_wait() to signal the workers</li> </ol> <p>Unfortunately (as the OP notes), in the next iteration, no worker will be woken up until the previously activated worker finishes its job.</p> <p>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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload