pthread switch (was Odd KSE panic)

[Daniel Eischen]

On Tue, 6 Jul 2004, Daniel Eischen wrote:

> On Tue, 6 Jul 2004, Andrew Gallatin wrote:
> 
> > 
> >  > does your worker thread loop to check if there is more work before
> >  > waiting to be notified?
> > 
> > Yes.  He takes a mutex, loops over all completed events, sending
> > pthread_signals as required, then releases the mutex and sleeps via
> > an ioctl.
> 
> Note that he is holding the mutex while calling pthread_cond_signal().
> If we enable preemption in pthread_cond_signal(), then I suspect it
> would be even worse than without preemption.
> 
> I think the only place where it is sane to enable preemption is
> on pthread_mutex_unlock().

Wewll, I just took a look at this.  I had already added a preemption
point in pthread_mutex_unlock():

  $ cvs log -r1.38 lib/libpthread/thread/thr_mutex.c
  ...
  description:
  ----------------------------
  revision 1.38
  date: 2003/07/18 02:46:29;  author: deischen;  state: Exp;  lines: +10 -6
  Add a preemption point when a mutex or condition variable is
  handed-off/signaled to a higher priority thread.  Note that when
  there are idle KSEs that could run the higher priority thread,
  we still add the preemption point because it seems to take the
  kernel a while to schedule an idle KSE.  The drawbacks are that
  threads will be swapped more often between CPUs (KSEs) and
  that there will be an extra userland context switch (the idle
  KSE is still woken and will probably resume the preempted
  thread).  We'll revisit this if and when idle CPU/KSE wakeup
  times improve.

Note that the priority of a runnable thread must be strictly greater
than the currently running thread in order for preemption to occur.

-- 
Dan Eischen