Re: About Multiprocessing

["Joel Sherrill <joel at OARcorp dot com>" <joel dot sherrill at OARcorp dot com>]

Eric Valette wrote:
> Joel Sherrill <joel@OARcorp.com> wrote:
>
> > Karel Gardas wrote:
> >
> >
> > > Hello,
> > >
> > > this is interesting, why is this this way? Nobody contributed SMP
> > > support yet, or does real SMP support hurts real-time functionality?
> > > Or is this just "historic relict"?
> >
> >
> > Yes.  Not really I would think.  Yes.
>
>
> As the SMP stuff periodically pops up, I always say the same thing:
> current RTEMS locking sheme is absolutely not convénient for SMP systems
> as it basically use IRQ disabling. This of course does not work on SMP
> but replacing "irq disabling lock" by other locks (e.g masked spin
> locks) would not work either because "irq disabling lock" can be nested
> and unordered while SMP locks cannot usually.

Inside RTEMS proper, there really shouldn't be any cases of interrupt 
disable nesting.  The code is written so if it did happen, the world 
wouldn't end but it was generally avoided as wasteful.

Now that doesn't mean there aren't cases, only that care was taken to
avoid them.

I don't disagree that the selection of SMP locking protocol would be 
tricky.  I was really only saying that I don't think it changes where 
the critical sections are in the source code.  Since they are always 
entered and exited by specific routines, it would be possible to replace 
those critical section management routines without massive changes.

--
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985