Brian Pane wrote: > > [EMAIL PROTECTED] wrote: > > >__pthread_alt_unlock() loops through a list of threads that are blocked on a > >mutex to find the thread with the highest priority. I don't know which mutex > >this is; I'm guessing it's the one associated with worker's condition variable.
> The leader/follower MPM might solve this problem. It doesn't share one > big condition variable among all the idle workers; instead, each worker > has its own condition var. sounds promising. Also, I wonder if it will reduce context switching noticably. That might help with schedule() cycles. I guess it depends on how frequently worker's listener thread blocks/unblocks in accept() when I pound it. > If you have time to try the 2.0.41 version > of leader/follower in your test environment, I'd be really interested > in hearing whether it fixes the __pthread_alt_unlock() bottleneck. I won't be able to try it near term, but hope to before too long. It will probably be on a uniprocessor, but the problem ought to show up there as well. Greg
