NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pthreads condition variables 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

Home | Main Index | Thread Index | Old Index