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

[Dennis Lee Bieber <wlfraed@ix.netcom.com>]

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}). 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/