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!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Sun, 13 May 2018 16:41:51 +0300 Organization: Tidorum Ltd 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net nsz0b6U6apLN+SDNmmpNug91FQXy2IeGfK1OR096gEaqL9LtsB Cancel-Lock: sha1:neoh+XeQVfKDmN+ozq1l2HQB7bQ= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader02.eternal-september.org comp.lang.ada:52337 Date: 2018-05-13T16:41:51+03:00 List-Id: On 18-05-12 23:01 , Dennis Lee Bieber wrote: > 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}). Yes. But why cannot the same approach be taken for dynamic allocation from the system heap? That is, there could be a requirement saying that the program should reboot if an allocation from the system heap fails. I've seen two motivations: One is that a system heap tends to degrade by fragmentation, preventing the embedded program from running for an indefinite duration, as is usually required. Another motivation is that it is too hard to understand and foresee the conditions under which the system heap could become full; the users (operators) of the program could not be given a rule-book saying what is allowed (certain not to cause heap overflow) and what is risky (might cause heap overflow). I have not kept up with heap structures, but I would assume that fragmentation can be avoided, at least if the size spectrum of an application's heap allocations is known. The second problem could be approached by some kind of quota system for various kinds of data, or (equivalently) by separate heaps dedicated to specific kinds of data. > 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) If you a priori forbid dynamic heap allocation at run time, then yes, you will not leave any memory for the heap (after initialization, at least). But that is your choice. > Dynamic allocation, by everyone I know, implies asking for memory to be > added to the process space while it is running. Huh? That seems to be confusing "malloc" with "sbreak", to speak in Unix terms. As you just said, above, an embedded bare-metal program already owns all of the memory the machine has, so there is no way to ask for more. The question is if some of the memory should be organized into a heap, or into several heaps, or other kinds of dynamically allocated memory. > 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. Ok, that shows two more possible motivations for not using system heap: variability of the time required for allocation (and perhaps for release, too), and the need to use locks if the heap is shared by multiple tasks. But some heap structures have good WCET bounds (buddy systems, for example), and many acceptable data structures need locks (inter-task message queues, for example). So I don't feel that these motivations are as strong as the two I quoted above. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .