General kernel question about waiting for events

General kernel question about waiting for events

[Maxim Levitsky]

Hi,

I am writing a device driver now, and am am learning to do so at same
time I can say...

I found one interesting feature of the scheduler, and I want to confirm
that I understood it correctly.

Suppose application wants to wait for an event, and doesn't specify any
timeouts.

In that case, wrapped in different packages, it always ends with
following loop:

while( event == false )
schedule();

Now suppose event doesn't happen soon, and system has no other runnable
tasks.

In that case I suspect that system will be in endless loop switching
between idle task (swapper) and this one.

Since its unknown when the event will became true, I don't think that
idle task will be able to put cpu to low power state.

Since on any system there are plenty of tasks that are blocked on
sockets, and don't use any specified timeout, I don't understand how
idle task could run.

I suspect that idle task will run for some predefined time anyway.
It uses need_resched() as an end condition.
But then, am I right that any thread that specifies wait on any event,
will actually force system to wakeup every that 'predefined time'
Which I suspect is 1/HZ seconds?
How longer wait can be done then?

Could you explain that to me a bit?

Another thing I think is wrong is the description for
wait_event_interruptible_timeout

It says, 'sleep until a condition gets true or a timeout elapses',
however it actually tests condition once, sleeps whole timeout, and then
returns.

So a naive user could call that function with large timeout, and think
that as soon as he sets the event, the wait will end.

Am I wrong here?

Best regards,
Maxim Levitsky

Re: General kernel question about waiting for events

[Alan Cox]

> In that case, wrapped in different packages, it always ends with
> following loop:
> 
> while( event == false )
> schedule();

No. If it were to do that then real time processes could spin eating the
CPU forever.

There is a difference between rescheduling and sleeping for an event.
Sleeping for an event (ie on a waitqueue) means that you will not be
woken until the wait queue is woken (or certain other things like signals
if interruptible). Rescheduling gives the CPU to someone else if anyone
wants it.

In short the different task states that are set are the important bit to
look at to understand this further.

Re: General kernel question about waiting for events

[Maxim Levitsky]

On Wed, 2009-12-02 at 00:24 +0000, Alan Cox wrote: 
> > In that case, wrapped in different packages, it always ends with
> > following loop:
> > 
> > while( event == false )
> > schedule();
> 
> No. If it were to do that then real time processes could spin eating the
> CPU forever.
> 
> There is a difference between rescheduling and sleeping for an event.
> Sleeping for an event (ie on a waitqueue) means that you will not be
> woken until the wait queue is woken (or certain other things like signals
> if interruptible). Rescheduling gives the CPU to someone else if anyone
> wants it.
> 
> In short the different task states that are set are the important bit to
> look at to understand this further.
Thanks you very much!

I already begin to investigate in that area, but your answer sums
everything up, sorry for silly (as I expected) question.

So, current task state is set to TASK_UNINTERRUPTIBLE or
TASK_INTERRUPTIBLE which differ in signal delivery (that I understood,
the TASK_INTERRUPTIBLE will break the wait when signal is received) but
both mean that current task is removed from scheduler pool until it is
woken up, or in case of schedule_timeout() also after the timeout
expires.
Also wait_event_interruptible_timeout does check the condition to avoid
useless sleeps, but if another thread or interrupt handler want to wake
it up, it not only sets that condition (it is optional at all) but
actually wakes the task up using literally wake_up() or related
functions.

Best regards,
Maxim Levitsky