This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Current state of SMP in eCos


On Thu, Dec 18, 2008 at 10:45 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> For running it on linux synth with mulitple threads, would that just
>> require starting a second thread somewhere in the synthetic startup
>> code? Will the threads be able to share memory? I've never done
>> multi-threaded programming on anything other than a flat memory model
>> RTOS.
>
> We would probably want to use the clone() system call. This is the
> basis for POSIX threads on linux. Threads share the same address space
> so yes, they can share memory.
>
>   Andrew
>

In the file SMP.txt (in packages/kernel/current/doc), there is a list
of requirements for SMP. I put the short form of the description here
along with my comments.

- Modest multiprocessing.
For a first pass I will "define" the same number of CPU's as max, so
they will be contiguous. If someone finds an issue for sparse CPU
usage that needs development, I think someone could modify this in the
future to support that.

- SMP synchronization support.
I think theoretically I can use the assembly language spinlock code
that is in the i386 smp code. But there is probably a linux call for
test_and_set. Would that be preferred?

- Coherent caches.
Should be a non-issue, right?

- Uniform addressing.
Should be a non-issue, right?

- Uniform device addressing.
Should be a non-issue, right?

- Interrupt routing.
Will this happen by default? I think the interrupts on synthetic are
simulated with signals. Will those be tied to one particular thread?

- Inter-CPU interrupts.
For the synthetic target, I will send a signal from one thread to the
other thread, correct?

- CPU Identifiers.
Is there a way to make a "private global" (private as in per-thread,
global as in global scope) variable for each "cpu"? Each thread is
going to have it's own stack, so theoretically the variable could be
stored there. But I don't know if there is any way to make that
actually happen. The other option is to get the PID and do a look-up
each time it is needed. But this seems to be very "expensive". But
since this is only a simulator, that is acceptable?



I also have one basic eCos question. I created a hal_smp.h file in
packages/hal/synth/arch/current/include. But it does not seem to get
copied to the build directory after ecosconfig tree and make. But I
couldn't find any magic that makes that work for the i386 version of
SMP. But it does. What is the trick to make that happen?

Thanks
David

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]