Re: How to get Ada to ?cross the chasm??

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 18-05-12 23:01 , Dennis Lee Bieber wrote:
> On Sat, 12 May 2018 22:04:32 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> 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
       .      @       .