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


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

Correct

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

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

Should be.
 
> - 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?

Signal handling in unix threaded programs always confuses me. What i
understand is that any thread which does not have the signal masked
can receive the signal. Trying to route a particular signal to just
one thread seems difficult and error prone. So it is best to assume
any thread will receive the signal.

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

Yep. This is something which you need to test alot to make sure the
thread you want to receive the signal actually does receive the
signal.

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

gcc has the thread local storage attribute:
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html

I don't know what support it needs from the linker and libc. synth
does not link with the system libc, so maybe this is not easy to get
working.

I don't think your "expensive" solution is going to be used very much,
so i would just start with that. You can optimize it later if needed.

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

It should just work. For problems like this i generally delete my
whole working tree and start again from scratch.

      Andrew

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