Re: [ECOS] Current state of SMP in eCos

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "David" == David Brennan <ecos@brennanhome.com> writes:

    David> 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.
    
    <snip>
    
    David> - SMP synchronization support.
    David> I think theoretically I can use the assembly language
    David> spinlock code that is in the i386 smp code. But there is
    David> probably a linux call for test_and_set. Would that be
    David> preferred?

In addition to what Andrew has already said:

First, you need to worry about the priorities of the Linux threads
running the virtual eCos cpu's. These should not use the default Linux
scheduling parameters SCHED_OTHER. If you did, the priorities of the
various threads would change dynamically depending on cpu vs. I/O
load, which is sensible behaviour for typical Linux threads but not
when you are trying to emulate cpu's that should all be running at the
same speed. Instead I think you'll need to specify SCHED_RR.

Second, if you have more virtual eCos cpu's than physical Linux cpu's
then you do not want to use the existing x86 spinlock code. That
assumes that all the cpu's are running continuously, so a spinlock
will only ever be held for a short period of time. If, say, you are
running two virtual eCos cpu's on a single-processor host then that
will certainly not be the case. Instead a virtual cpu trying to claim
a locked spinlock will keep spinning until the timeslice for the
underlying Linux thread is used up, and another Linux thread running
the other virtual cpu wakes up again.

A better approach might be to call Linux's sched_yield() when trying
to claim a spinlock that is already locked, giving the Linux thread
that currently holds the spinlock more of a chance to run.
Alternatively it might be possible to implement an eCos spinlock using
an underlying Linux pthread mutex, but that is likely to use rather
more cpu cycles.

The various implementation details of all this are left as an exercise
to the reader.

There is at least one other issue you need to think about: the
interaction between the eCos application and the synthetic target I/O
auxiliary in synth_intr.c. I do not know offhand how safe that code
will be in an emulated SMP environment. For example, what is going to
happen if one virtual cpu tries to send an ethernet packet while
another virtual cpu is trying to send some diagnostics output to the
screen and a third cpu is busy servicing an interrupt. Tracking down
SMP-problems in your application code is going to be hard enough, you
don't want additional problems because you have not yet made the
underlying I/O subsystem SMP-safe.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

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