Re: Standard Queue status

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

Well, not exactly from the compiler. More like this:

If I build a program with 100 elements in an array, then test the program
with all 100 elements in use, I now know if it can meet its performance
requirements as built. I can't possibly get 101 elements into it and have
that be the camel that breaks its straw back. I'd have to rebuild the
software tweaking that size upwards - presumably I'd be smart enough to test
the *new* worst case. For sure I know I've got a different set of bits now
and the verification of the original bits is null and void.

If its a dynamic list, I can have it allocate 100 elements and feel
confident that my accessing of those 100 elements is time-wise consistent if
I understand my design, etc. But what if the next execution of the program
ends up with 101 elements - oh, say, because a user tweaked something or an
unusual condition came up or something in the environment changed, or
whatever. If that 101'st element is the one-too-many camels, the house of
straw gets blown away by the big bad wolf.

I'm not saying you can't build hard real time with dynamic lists - it just
means you've got to be real careful about your design and understand its
limitations, etc. Asking "Did I design it to behave deterministically and
have a worst case scenario that I can test?" is a good idea. If you're
there, then O.K. I just think it is simpler with a fixed allocation.

It also depends on your relative level of paranoia. :-)

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/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:KQwN7.42765$xS6.72463@www.newsranger.com...
>
> 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.
>