On Thu, 22 Feb 2001, Stephen D. Cohen wrote:
> I can not think of any way that this can be done. The ISRs in
> RTLinux run within the context of the process which was running when the
> interrupt came in. Thus there is no way to be sure that the interrupt does
> not get pre-empted by the scheduler, unless you are certain that the
> interrupted task is the only computable process.
>
> I am sure, however, that if you are trying to use pthread_suspend_np
> from an ISR, you are probably doing something the hard (very hard) way. In
> general ISRs wake things up, not put them to sleep.
>
> Perhaps if you provided some details of your application I/we could
> help you with your design.
>
> > With RTLinux 2.0 it seems I can't call pthread_kill...is it right ?
>
> ?? 2.0 ?? First bit of advice, upgrade to 3.0 - many many many
> fixes.
>
> Also, as an aside, when you do a pthread_wakeup_np from an ISR, you
> have to keep in mind that the ISR will probably be pre-empted immediately.
> Thus you should get all of your hardware tweaking, etc. that needs to be
> done in a highly-deterministic ISR sort of way done *first*, before calling
> the wakeup. The system will go and serve the woken process and will return
> to call the IRET in the ISR when that process goes back to sleep. This is,
> of course, assuming that you have all of your priorities set in a "normal"
> manner.
>
> This sort of "odd" quasi-inverted mechanism was implemented to
> prevent having to call the scheduler (expensive) with every interrupt. Thus
> systems with interrupt driven serial I/O, for example, can avoid a bazillion
> calls to the scheduler.
Stephen,
thanks for your two interventions on the subject, they helped me
understand that pthread_wakeup_np from an ISR is probably useful for my
case.
Without boring you with details, the structure of my ISR is:
I_handler{
/*Data acquisition*/
/*Computations*/
pthread_wakeup_np(my_thread);
}
While computations have to be done before the next interrupt, stuff done
in my_thread has not this restriction (In other words it'a sort of
background task).
If I understand what you wrote it's not a problem if my_thread doesn't
finish his work before the next interrupt. I_handler will execute anyway.
Is all this too contorted ? Does a simpler way exists ?
Thanks again,
Stefano.
-- [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/
