About Multiprocessing

Joel Sherrill <joel@OARcorp.com> joel.sherrill at OARcorp.com
Tue Dec 20 13:34:08 UTC 2005

Jiri Gaisler wrote:
> We are currently developing an MP system with four LEON3 (SPARC)
> cpus in a shared memory configuration. We are using the MP extensions
> and memory-based communication, works fine so far. Pitty that RTEMS
> doesn't have support for SMP, i.e. one image with multiple threads
> executed by multiple cpus. eCos has this and it scales well up to
> ~ four processors. With RTEMS, we must have a separate image for each
> cpu, which wastes memory and complicates linking and program loading.

If you have a way to tell which node you are on, the same text image 
could work.  One copy of the code but multiple workspaces and BSSs.

Given that all of RTEMS internal locking is handled by a couple of 
critical section routines, it shouldn't be terribly difficult to fix 
that part of the issue.  But the slightly harder issue is scheduling 
multiple threads.  I don't think it would be terribly difficult to 
address either.  _Thread_Executing must reflect a set of threads and the
logic for the relationship between those two must be examined.

Sounds like nice work for spring time if someone wants this to happen. :)


> Jiri.
> Ralf Corsepius wrote:
>> On Tue, 2005-12-20 at 20:11 +1100, Angelo Fraietta wrote:
>>> there are over 40 CPUs (or rather BSPs) that RTEMS SUPPORTS
>> ... but only 3 of these BSPs claim to support multiprocessing:
>> m68k/mvme147s, m68k/mvme136, powerpc/psim :)
>> i.e. multiprocessing for all cpus but the m68k and powerpc, probably has
>> never been tested at all ;)
>> Ralf
>> .

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

More information about the users mailing list