Re: [squid-users] Squid Performance Issues - reproduced

Robert Collins wrote:

> Nope. cond_signal is 1 or more releases.

In all documentation I have seen cond_signal signals exacly 1 thread per
call while there is threads waiting on the condition.

> Huh? The state should be (slightly compressed):
> thread S, W1, W2
> active B-waitingforsignal B-waitingforsignal

for clarity this should be added:
  mutex_lock() B-waitingforsignal B-waitingforsignal

> cond_signal() B-inpthread_mutex_lock B-waitingforsignal
> cond_signal() B-inpthread_mutex_lock B-inpthread_mutex_lock
> mutex_unlock() active B-inpthread_mutex_lock
> active mutex_unlock() active
> active active active
>
> Ok, whats high overhead in the current model? I'll check the code in
> detail in the weekend.

The main issue is that there is no guarantee a thread is started in a
timely fashion if there is CPU congestion, or that the thread gets CPU
to perform it's thing.

For UP systems it would probably do good if we could somehow force a
reshedule per comm loop if there is pending I/O to be taken by the
threads. For SMP systems this is a non-issue.

> Ah. Well, what about:
> pthread_mutex_lock(&queuemutex)
> do {
> schedule_io_request()
> pthread_cond_signal()
> } for <count> requests
> pthread_mutex_unlock(&queuemutex)
> pthread_mutex_lock(&queuemutex)
> pthread_mutex_unlock(&queuemutex)

By intention the main thread never uses pthread_mutex_lock, only
pthread_mutex_trylock. This to avoid lock congestion.

Also, initial tests indicates mutex_unlock does no more than makes the
mutex available and signal the scheduler to wake up one (or more) of the
blocked threads. If you lock it immediately again your will most likely
reaquire the lock before any of the blocked threads have a chance to it.
And this makes perfect sense. Mutexes is not about scheduling but about
locking.

I have seen nothing in the mutex documentation specifying which thread
whill get the mutex.

Regards
Henrik
Received on Thu Jan 02 2003 - 18:26:19 MST