cvs commit: src/sys/cam/scsi scsi_target.c src/sys/codacoda_psdev.csrc/sys/dev/firewire firewire.c src/sys/dev/kbd kbd.c src/sys/dev/nmdm nmdm.

[Bruce Evans]

On Sun, 9 Nov 2003, John Baldwin wrote:

> On 09-Nov-2003 Seigo Tanimura wrote:
> > tanimura    2003/11/09 01:17:26 PST
> >
> >   FreeBSD src repository
> >
> >   Modified files:
> >     sys/cam/scsi         scsi_target.c
> >     sys/coda             coda_psdev.c
> > ...
> >   Log:
> >   - Implement selwakeuppri() which allows raising the priority of a
> >     thread being waken up.  The thread waken up can run at a priority as
> >     high as after tsleep().
> >
> >   - Replace selwakeup()s with selwakeuppri()s and pass appropriate
> >     priorities.
> >
> >   - Add cv_broadcastpri() which raises the priority of the broadcast
> >     threads.  Used by selwakeuppri() if collision occurs.
> >
> >   Not objected in:        -arch, -current
>
> Sorry I didn't speak up on arch@, just too busy.  But, why do you need
> to bump up the priority of the thread you are waking up?

I left the reply to someone else :-).

The priority may need to be bumped because the thread is a user thread that
is sleeping at a low user priority.  As I understand this change, the
thread priority may be low for cases that don't use tsleep() so they can't
set the thread priority using that.  So this changes is needed to get the
same behaviour as using tsleep().  However, I think that behaviour is not
quite right -- if the thread is a user thread then it waking it up is only
urgent if it needs to do some urgent things in kernel mode on wakeup.  It
should not return to user mode until its user priority permits its
scheduling.  However2, we still have the bugfeature that user threads keep
the kernel priority that they wake up at all the way back to user mode,
and this may be necessary for interactivity.

Bruce