> Okay, I checked Rubini's book, and he has a solution which seems elegant
> enough (Alan suggested it in a previous post, but here's the full
> expansion).
> Here's the code:
>
> struct wait_queue wait = {current, NULL};
>
> add_wait_queue(&my_q, &wait);
> current->state = TASK_INTERRUPTIBLE;
> play_with_my_hardware_which_will_eventually_generate_an_interrupt();
> schedule();
> remove_wait_queue(&my_q, &wait);
>
> my_isr()
> {
> ...
> wake_up_interruptible(&my_q);
> ...
> }
>
> The story is that if the interrupt beats the schedule(), then the task
> will be set to state TASK_RUNNING via the wake_up_interruptible call, and
> the process removes itself from the wait queue. This should work well
> enough, but I still think that having a bulletproof version of sleep_on is
> far more elegant, and may prevent some painful mistakes for driver
> writers.
> Just one more question (I'm new to linux drivers, was in NT driverland
> till recently, glad to get the needle out of my vein :)
> In the code above, is there any possibility of the process' state being
> changed prior to the schedule() call (i.e. can nonblocking kernel code be
> context-switched out?)
Absolutely. I presume, your 'code-part' is via an ioctl(), read(), write()
or something called from user-space. Any part of the code could be
interrupted and/or switched out at any time. That's why I think you
need a lock. In your code-snippet above, you only execute schedule()
once. This just gives up the CPU for one 'trip around the queue' of
computable tasks. You may get control long before the interrupt occurs.
The sleep_on_timeout() keeps scheduling until you ether time-out or
the interrupt occurs.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : The end of the world as we know it requires a new calendar.
Seconds : 122618 (until Y2K)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/