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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 12 May 2018 15:01:29 -0500 From: Dennis Lee Bieber Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Sat, 12 May 2018 16:01:29 -0400 Organization: IISS Elusive Unicorn Message-ID: References: <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> <87po27fbv9.fsf@nightsong.com> <87in7x62vw.fsf@nightsong.com> <878t8szdtk.fsf@nightsong.com> <87tvrdhl5v.fsf@nightsong.com> User-Agent: ForteAgent/8.00.32.1272 X-No-Archive: YES MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 108.68.179.11 X-Trace: sv3-JxjyJ6wtnGGmhFshtWeIFR6BPCKhc5FJus6yLSwp4WyWJtbnn5eQ22kScAPp31BjA5IjhmXtnXN5hNY!EdMh1Rjw6LGXlmj1+M1klnpL3J6H5nRKNToA+6gdLKfB4xJBxXzhIgN/f3gzC8RBKuRneAS+FO/Z!Ozf5wSluFo314Sub/vdAeg+QIgQ= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4054 Xref: reader02.eternal-september.org comp.lang.ada:52327 Date: 2018-05-12T16:01:29-04:00 List-Id: On Sat, 12 May 2018 22:04:32 +0300, Niklas Holsti declaimed the following: > >Yes, if the static array can become full in a way that prevents the >program from continuing normally. > Then the program is erroneous either in design or specification -- it either requires larger array/buffers from the start, or the requirements need to state what should be done when the existing buffer is filled (drop new data, drop old data, log an exception and reboot {and yes, that IS a valid design option}). The buffer space is a process fixed quantity once initialization has completed; one can not, upon filling a buffer, ask the system to allocate more memory to the process. In effect, the heap only exists during initialization, and once transitioned to "running" there is no more available heap -- anything left might be stack space (though often even the stack is a predetermined/fixed size) Dynamic allocation, by everyone I know, implies asking for memory to be added to the process space while it is running. >The question that interests me is: if dynamic allocation in the system >heap is too risky for critical SW, where in this spectrum of dynamic >memory allocation mechanisms does that risk go away, and why? And if >some risk remains in the mechanism that I would like to use for the SW, >what should/must I do to defend against that risk? As mentioned, the SW requirements should state what the expected behavior is should a produce fill a buffer faster than a consumer empties it. And as I mentioned, that could be "drop earliest", "drop newest", log/reboot (on the basis that the SW/HW appears to be malfunctioning, a reboot will clear memory and reset hardware devices). Attempting to allocate new memory while running changes timing behavior: incrementing a pointer and comparing to a limit is constant time, and either succeeds (not full/empty) or fails (full/empty) with defined processing. Increment/compare followed by optional "ask system to find a new chunk of memory for the process" has indeterminate timing; especially if the request also fails -- and if such dynamic allocation of memory to a process were to be permitted, it would likely need to have locks around it so that a mult-process system doesn't have two processes trying to allocate memory at the same time... Timing impact across processes. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/