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

On Fri, 2003-01-03 at 12:12, Henrik Nordstrom wrote:
> 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.

Well, I quoted a counter example. The cygwin pthreads code I maintain
releases exactly 1 thread though.
 
> 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.
...
> By intention the main thread never uses pthread_mutex_lock, only
> pthread_mutex_trylock. This to avoid lock congestion.

The second use of pthread_mutex_lock I described, will force a
reschedule per comm loop if there is pending I/O.
 
> 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.

The thread that next gets a cpu will get it, and that is determined by
the scheduler. You can use thread priority to determine this - a higher
priority thread will get the mutex before a low priority one, with the
exception being priority inversion avoidance code, should it trigger.

Rob