[lkml]   [2004]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: timing code in 2.6.1
"Richard B. Johnson" <> wrote:
> Some drivers are being re-written for 2.6++. The following
> construct seems to work for "waiting for an event" in
> the kernel modules.
> // No locks are being held
> tim = jiffies + EVENT_TIMEOUT;
> while(!event() && time_before(jiffies, tim))
> schedule_timeout(0);
> Is there anything wrong?

This is not a good thing to be doing. You should add this task to a
waitqueue and then sleep. Make the code which causes event() to come true
deliver a wake_up to that waitqueue. There are many examples of this in
the kernel.

If the hardware only supports polling then gee, you'd be best off spinning
for a few microseconds then fall into a schedule_timeout(1) polling loop.
Or something like that. Or make the hardware designer write the damn

> Do I have to execute "set_current_state(TASK_INTERRUPTIBLE)" before?
> Do I have to execute "set_current_state(TASK_RUNNING)" after?
> I don't want to have to change this again so I really need to
> know. For instance, if I execute "set_current_state(TASK_INTERRUPTIBLE)"
> in version 2.4.24, it didn't hurt anything. In 2.6.1, there are
> conditions where schedule_timeout(0) doesn't return if another
> task is spinning "while(1) ; ". This is NotGood(tm).

As you have it, you may as well be calling schedule() inside that loop.
You _have_ to be in state TASK_RUNNING, else you'll sleep forever.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:00    [W:0.106 / U:1.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site