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 10:21:21 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> 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 13:21:09 EST Organization: http://www.newsranger.com Date: Thu, 29 Nov 2001 18:21:09 GMT Xref: archiver1.google.com comp.lang.ada:17177 Date: 2001-11-29T18:21:09+00:00 List-Id: In article <9u5ll7$ron$1@nh.pace.co.uk>, Marin David Condic says... > >"Stephen Leake" wrote in message >news:ubshlheoj.fsf@gsfc.nasa.gov... >> >> lists must be efficient enough for hard real-time use >> >I don't think this was a requirement and would be hard to meet if any sort >of dynamic allocation is being done. It isn't so much an efficiency issue as >it is a determinism issue. IIRC, there seemed to be some consensus that a 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. >> lists must be safe in a multitasking environment >> >It would be nice to have a flavor of lists that met this requirement, but I >think the general feeling was that a) it wasn't needed for v1.0 and b) the >user could do this for themselves by encasing the list in a protected type. I believe that is what we got to. However, I do think that at least the routines themselves should be re-entrant. It should be possible for a user to make things task-safe by synchronizing all accesses to the same list object. That would give us the level of safety folks have come to expect from the standard Ada library. --- 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.