On Mon, Feb 21, 2000 at 01:35:45AM -0800, Robert Kavaler wrote:
> > In the real-time task, use the following loop:
> >
> > while (1) {
> > pthread_suspend_np(pthread_self());
> > // handle the interrupt
> > }
> >
> > Then install a RT interrupt handler using rtl_request_irq (there is a manual
> > page in the distribution).
> > In the interrupt handler call pthread_wakeup_np(thread) to
> > wake the real-time thread up.
> >
> I noticed that in revisions 2.0 and 3.0 that the wakeup directly sets the
> runnable flag of a task and therefore in the code above, if an interrupt
> occurs before the suspend, the ISR will wakeup a non-suspended task, and then
In 2.2 (and soon, in 3.2 ) you will can solve this problem by
> the task will be suspended forever. This problem is usually solved by testing
> if the interrupt occurs with interrupts OFF before the suspend and then
> suspending with interrupts off. The scheduler would then turn interrupts
> on and run until the task is woken up at which time the task would re-enable
> interrupts and continue. Is this what one should do?
That works and is the simple solution -- although it fails on SMP systems.
I'm planning on making the Plan9 "sleep(conditionvar)" available
this would do something like
while(!conditionvar.cond){
disable interrupts
spinlock conditionvar.lock
if(!conditionvar.cond){
pthread_kill(pthread_self(),SUSPEND);
unlock conditionvar.lock
sigwait();
}
else {
unlock conditionvar.lock
return;
}
}
> I noticed also that in revision 2.2 that the wakeup does not set the
> runnable flag, instead it sets a wakeup flag and clear the suspended flag.
> In theory this would get around the problem above assuming that suspend
> would set the suspended flag (and not clear the wakeup flag),
> and the scheduler would give priority to the wakeup. In this way,
> if an interrupt occurs during execution of the task, then suspend would
> just essentially be ignored. Unfortunately, when I look at suspend it clears
> the wakeup flag and doesn't set the suspended flag. So I'm confused.
> How does the task actually get suspended? What is the intent
> moving forward, should I protect the suspend by disabling interrupts, or
> will this be handled by the scheduler?
At the start of rtl_schedule, there is a call to do_signal which
makes the thread state SUSPENDED if the SUSPEND signal is pending
and makes the thread state READY if the WAKEUP signal is pending.
The intention here is that sending a signal is a fast operation that
causes the destination thread to suspend the next time the scheduler runs.
All the signal implementation is in flux, although the semantics should
stay fixed.
> (BTW, the 2.1 code appears to half way between 2.0 and 2.2, but functions
> more like 2.0 since it sets the runnable flag directly.
>
> Robert Kavaler
> [EMAIL PROTECTED]
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/~rtlinux/
--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
