kern_yield vs ukbd_yield

[Andriy Gapon]

Replying further...

on 16/12/2011 00:56 Hans Petter Selasky said the following:
> On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote:
>> Hmm... I looked at the history of ukbd.c (which I should have done from the
>> very start) and I see two relevant revisions:
>> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=2
>> 03896&pathrev=203896
>> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2=
>> 223989&pathrev=223989
>>
>> So, first use of pause(9) was introduced to work around current broken
>> syscons polling mechanism.  Then pause(9) was replaced with the
>> hand-rolled yield to fix a problem at shutdown, which supposedly was
>> caused by times being stopped.
>>
>> None of the commits seems to be directly related to thread priorities. 
> 
> Not directly, but indirect. You know, if you pause thread 1 (which I thought 
> was thread 0), then other thread will get a chance to run.

pause() could be a sufficient action to let other thread run, but it is not a
required action.  As we've already discusses earlier all the USB threads have
sufficiently high priorities to get runnable while other kernel threads are
runnable.  Only certain interrupt threads could have prevented them from
running, but that's definitely not the case.

> It might also be that Giant is locked by syscons, and that unless you pause or 
> yield, then Giant will block other parts of USB, like the callback thread, 
> which is Giant locked for ukbd only to run.
> 
> Maybe that is the explanation?

Not sure if you are hypothesizing or if this is something that you experienced
during development and testing.

Let's consider a few observations.

First, syscons doesn't acquire Giant anywhere in the path started from cngetc.
Actually, I believe that the only place where Giant is now explicitly acquired
in the whole syscons code can be safely replaced with an assert that the Giant
is already held.

Second, the polling mode is designed to be usable in situations where other
threads are not running.  So in general it should not depend on other threads
being able to make any progress.

-- 
Andriy Gapon