Re: [ECOS] Stack switching

[Tim michals <tcmichals at yahoo dot com>]

Another possiblity maybe to use a coroutine library on top of a single thread, for example: then gdb and ecos does not have to change...
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
http://www.sics.se/~adam/pt/about.html



----- Original Message ----
From: Andrew Lunn <andrew@lunn.ch>
To: Paul D. DeRocco <pderocco@ix.netcom.com>
Cc: eCos Discuss <ecos-discuss@ecos.sourceware.org>
Sent: Sunday, January 7, 2007 5:24:17 AM
Subject: Re: [ECOS] Stack switching


On Sat, Jan 06, 2007 at 04:45:30PM -0800, Paul D. DeRocco wrote:
> > > Paul D. DeRocco wrote:
> > >
> > > If I explicitly switch stacks in an eCos thread, will this break 
> > > anything in the kernel, or in the eCos extensions to GDB?
> 
> > From: Gary Thomas [mailto:gary@mlbassoc.com] 
> > 
> > How/when/why would you do this?
> > 
> > It could make a GDB backtrace fail, but that only happens if 
> > you ask for it.  Normal GDB functions should not be affected.
> > 
> > The kernel stack checking mechanisms would also break - only 
> > used if asserts are turned on.
> 
> I have an application which needs to do some co-operative round-robin
> multi-tasking, and I'm not sure I can get eCos to do this with multiple
> threads. The application is a musical synthesizer in which each note is
> represented by a separate thread, which computes continuous control signals
> like envelopes and vibrato on behalf of that note.
> 
> The requirements are:
> 
> 1. Each thread needs to do one iteration of an apparently continuous
> calculation, then yield to the remaining threads.
> 
> 2. The threads may not be time sliced. Each must do a complete iteration of
> its calculation, and then yield to the other threads. (They may be
> pre-empted by unrelated higher priority threads, however.)
> 
> 3. When a new note thread is created, it must be scheduled next in line for
> execution among these note threads, not last in line, so that the onset of a
> new note occurs as soon as possible.
> 
> The reason I want to use threads, instead of a list of functions to call, is
> that I want each calculation to be able to yield at different points in its
> program, including inside a nested function call, rather than having to
> restart at the beginning and rely on state variables to keep track of where
> its calculation is.
> 
> If I create multiple eCos threads, and give them all the same priority, then
> they can take turns executing and calling cyg_thread_yield. But this only
> works if I disable time-slicing. I'm not sure the rest of my system (e.g.,
> Ethernet driver, etc.) won't be unhappy about that.

The device drivers should work without round-robin. If not, its a bug
which should be fixed. 

> Also, the third
> requirement will be difficult to meet using eCos threads.

Actually, it is not that difficult. To set a new thread running you
call cyg_thread_resume(). This calls the thread class resume, which in
turn does:

Cyg_Scheduler::scheduler.add_thread(this);

which adds the thread to a run queue. 

You have two options:

Change add_thread() where it calls:

queue->add_tail(thread);

make it call add_head() so that the thread is placed at the head of
the queue. The disadvantage of this is that add_thread is also used
for waking up a thread when it has been sleeping. So newly woken
threads will also be placed at the head of the run queue, not the
tail. I expect this will just work, but you might find some subtle
problems with the test cases which make assumptions about what thread
gets to run when? Try it and see.

The second option is to add a new member function to the scheduler
class, add_thread_head() and make the resume function use that.

> Finally, I expect to have a large number of such threads (up to 64), and I'm
> afraid the thread-switching overhead may turn out to be significant.

The number of threads itself is not a problem. You are just doing
linked list operations on the head and tail. There are no search
operations needed which iterate over the list of threads. So it is
just the overhead of context switching you need to be worried about. 

> Since
> all these light-weight threads need to do is start, yield, and eventually
> die (they don't need to do system calls that might block), a simple stack
> switch mechanism would be much faster.
> 
> If I opt to switch stacks, would it be possible to keep the kernel stack
> checking happy, by also switching the kernel's record of the stack limits?
> And does GDB have its own idea of the stack limits, or does it just read the
> same values that the kernel uses?

I suspect i would just make the change above and see how it goes. If
you find you are having performance problems caused by context switch
overhead you can then take a look at writing your own light-weight
threads.

   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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

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