Re: pthreads condition variables

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

raymond.meyer%rambler.ru@localhost wrote:
> The problem here is when all 256 threads wake up at the same time, they
> will all try to lock the same mutex, creating a lot of contention.
> Because the data is partitioned into 256 parallel regions, each thread
> works on a different data set, hence no need for mutual exclusion.

From what I understand, it is the traditional worker thread model from 
Butenhof, which is based on what you say, except that the processed data 
is shared between threads (not your case).

You could split up the thing in 1/2, 1/3, 1/4... with multiple 
conditional variables, so that you reduce by an order of magnitude the 
contention on the different mutexes, without relying to the "one condvar 
per thread" model (actually, that is two, one to signal that there is 
data to process, and one to signal that the processing just finished).

IMHO, the "one condvar model to wake them all" is too much of a 
bottleneck, as when one of the region is filled, the associated thread 
is waiting for the 255 other regions to be filled (right when you will 
issue the broadcast).

> When
> a thread wakes up, it immediately calls pthread_mutex_unlock, which
> seems to be redundant, but necessary to allow other threads to continue.

No, it is necessary as the mutex protects a shared state, like a work 
queue. If the mutex_cond_wait returned with the mutex unlocked, there 
could be two threads working on the same queue at a time, generously 
poping/pushing items in it without locking, which is bad.

> The alternative is to have each thread sleep on its own private
> condition variable and mutex. This would require calling
> 'pthread_cond_signal' for each thread, that is 256 time in total.
>
> So is there a way to design a function similar to
> pthread_cond_broadcast, that doesn't cause each thread to lock the same
> mutex when it wakes up?

You mean a function to wake up different sleeping threads without 
relying to mutex protection? Seems hard, especially when you have to 
handle spurious wakeups.

Note that NetBSD uses adaptive mutexes, which means that the thread 
waiting on a mutex will spin-wait for it if the thread that acquired the 
mutex is concurrently running. This avoids unnecessary sleeps.

There's perhaps another solution, with a different locking model, or 
with lockfree algorithms. I don't know. You should try 
comp.programming.threads.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost