Re: Standard Queue status

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:p0vN7.42577$xS6.71670@www.newsranger.com...
>
> I believe it was more of a "should" than a "shall" requirement. You
clearly
> can't entirely get rid of dynamic allocation for an "unbounded" structure.
But
> what you can do is try to fix it so that once the structure is "set" (no
more
> deletions, additions, or moves), it can be used without any heap
allocations
> occuring. If its feasable to do this without violating a "shall"
requirement,
> there is no good reason to not design it that way.
>
I get your point. I'd agree to reentrancy and efficiency and lack of dynamic
allocation once the list is built - all of which just on general principle.
Even non-realtime stuff shouldn't suffer with needless inefficiency or
unpredictable behavior without good reason.

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:

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

The list should be made as efficient and predictable as is practical for a
dynamic data structure.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/