> 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?
> 
I still think that the implementation of suspend in 2.2 is wrong since it 
doesn't set the suspend flag, it just clears the wakeup flagi (which is
probably should not do).

> 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.

and if both flags are set wakeup has precedence over suspend.  Is that 
part of the POSIX standard, or just a coincidence?  It would be great
if wakeup always superceeded suspend, since that would solve the sleep
problem.

> 
> 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/
-- [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/

Reply via email to