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: Stack switching


> > 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. Also, the third
requirement will be difficult to meet using eCos threads.

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

Thanks in advance.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.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


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