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.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP 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 12:34:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!nntp-relay.ihug.net!ihug.co.nz!out.nntp.be!propagator-SanJose!in.nntp.be!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison 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> Subject: Re: Standard Queue status Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Thu, 29 Nov 2001 15:25:14 EST Organization: http://www.newsranger.com Date: Thu, 29 Nov 2001 20:25:14 GMT Xref: archiver1.google.com comp.lang.ada:17189 Date: 2001-11-29T20:25:14+00:00 List-Id: 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.