Re: Standard Queue status

[Ted Dennison<dennison@telepath.com>]

In article <9u61b8$3o9$1@nh.pace.co.uk>, Marin David Condic says...
>
>Obviously, a data structure of indeterminate size has real problems for
>"hard" real time systems. Behavior of the code now depends on the number of
>elements that are there at any given run. So really, anything other than a
>fixed (at *compile* time) sized structure would probably be unsuitable for
>hard realtime. Hence, I think the requirement should be restated:

You are right that there needs to be some kind of assurance up front that the
sheer size of the list won't make schedulability a problem. But it doesn't
always have to come from the compiler.

Often times our systems have lists whose size is set by the number of items put
in a configuration file somewhere. We do this so that we don't have to resort to
a compiler to make trivial changes. For a mass-produced simulator, the end units
that you need to debug are often quite far away from any compiler. 

For example, each scheduled "item" that our RT scheduler has to schedule is put
in a configuration file (along with stuff like what frequency it runs at, and
whether its disabled or not). This is obviously going to end up in a list. It
would be tough to concieve of a RT scheduler that *doesn't* use some kind of
list. The issue for us isn't how it handles additions, since those happen at
startup, or deletions, since those only occur when there's a fatal error. But we
do have to iterate through the list and access the items in real time. 

What this means is that there really is no reason why we can't use a dynamic
list, as long as its authors can restrain themselves from performing heap
operations during iterations and element fetches.

This is just one example. We actually have several lists like this that get
accessed in real time, based upon the information in some kind of configuration
file. At one point we had some engineers (ab)using our interpolation table files
for this purpose by making a bunch of single-row tables with a column for each
configuration item. They'd then try to avoid the interpolation logic by only
requesting data for columns which they knew to be in the table file. %-(

>The list should do allocation/deallocation of memory only to add or remove
>elements - not to access its contents.

Exactly. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.