From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fdc75443ea18fb32 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-29 14:57:26 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.icl.net!opentransit.net!fr.clara.net!heighliner.fr.clara.net!157.161.139.35.MISMATCH!27105950!news.imp.ch!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Standard Queue status Date: Thu, 29 Nov 2001 17:49:16 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9u6e1d$903$1@nh.pace.co.uk> References: <%QRM7.39743$xS6.65958@www.newsranger.com> <9u0qhb$pq5$1@nh.pace.co.uk> <9u0ujd$rhg$1@nh.pace.co.uk> <9u5ll7$ron$1@nh.pace.co.uk> <9u61b8$3o9$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1007074157 9219 136.170.200.133 (29 Nov 2001 22:49:17 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 29 Nov 2001 22:49:17 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:17197 Date: 2001-11-29T22:49:17+00:00 List-Id: 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" 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. >