On Tue, Jun 20, 2000 at 06:37:04PM +0200, Paolo Mantegazza wrote:
> Pavel Andris wrote:
>  
> > So, Victor, Paolo could you please make things clear for us? By the
> > way, in my application would ISR last several milliseconds (robot's
> > sample period computations, heavy use of FPU) that's why I tend to
> > "pay more than needed".
> 
> My opinion is not a must, is just an opinion. Take into account that all
> techinical solution are a tradeoff between conflicting needs.

My opinion is, of course, authoritative, absolute, and not to be
questioned.  -)

My opinion is that a multi-millisecond ISR is generally not a good idea. 
I would write things as

isr_catch_interrupt:
               count++;
               do something fast
               put some data somewhere 
               pthread_kill(compute_thread,RTL_SIG_WAKEUP);
               
               return


compute_thread:
             pthread_setfp_np(pthread_self());
        while(not_done){
             mycount = count;
             do the computation;
             rtl_no_interrupts(state);
             if(mycount == count)
                pthread_suspend_np(pthread_self());
             rtl_restore_interrupts(state);
             }
             
             


This needs some work for SMP if you allow the interrupt and 
thread to run on different processors, but the changes are not
complex. It is architecture independent and fast and, to me, it
is a clean design. It can be made even simpler by using a mutex, but
I have an irrational dislike of mutexes, so I didn't use them.



> You can do it as you want, my attitude is that Linux constraints are not
> mine. When I'm working in real time Linux must be my stupid servant and
> hardware is just mine.

My attitude is that ignoring Linux constraints is asking for trouble.
Of course, Paolo you know this already, but for the benefit of those
less expert:

Consider, for example:

/* this is Linux kernel code */
         save floating point
         do  a fp computation
             kmalloc();
         restore fp


And think of what happens when this runs on a SMP machine. What happens
is that the probability of a failure in test is low, but the 
probability of an eventual kernel crash is quite high.
The crash comes because the process may suspend during the kmalloc
and then Linux may decide to send it to a different processor!
Of course, you can fix this by making the save fp routine notify
the reassign code that the fp must be restored, but  you would
be better off not getting involved here in the first place.












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