pthread switch (was Odd KSE panic)

Julian Elischer julian at elischer.org
Sat Jul 10 21:49:16 PDT 2004



On Thu, 8 Jul 2004, Daniel Eischen wrote:

> 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.

So all Drew should have to do is increas the priority of teh correct
thread to get it to switch at that point.


Drew?



>
> --
> Dan Eischen
>
>



More information about the freebsd-threads mailing list