[SystemSafety] C for OSs

[Olwen Morgan]

Taking a more general view, There is a potential conflict between 
isarithmic bounding of resource usage and hard real-time response. 
Isarithmic constraints and corresponding algorithm design can ensure 
that you meet hard time and memory constraints. The price is that you 
sometimes have to turn down a demand for service. In systems where that 
is not allowed, you can use isarithmic design only if the system is 
adequately sized for the job at hand.

Isarithmic design does not technically preclude garbage collection 
because you can design it too to work isarithmically. The problem is not 
garbage collection /per se/ but whether or not it leads to violation of 
response and service constraints.


Olwen


On 09/09/2019 20:54, Roderick Chapman wrote:
>
>
> On 09/09/2019 18:30, Olwen Morgan wrote:
>> Agreed. Garbage collection is compatible with hard-real-time *if and 
>> only if* you can prove that the real-time constraints will always be 
>> met. I just wish that people would put more effort into developing 
>> garbage collectors that could meet such constraints.
>
> There have been several efforts along these lines. I remember the 
> functional programming community started on this back in the late 80s. 
> There's was also a "Haskell on Bare Metal" effort at Portland I think.
>
> Then there's Real-Time Java (both of 'em) which aimed, in at least 
> some implementations, to provide garbage collection that gave some 
> assurance of worst-case and/or amortized overhead. See the 
> implementations from either
>
> https://www.ptc.com/en/products/developer-tools/perc
>
> or
>
> https://www.aicas.com/cms/en/products
>
> for example.
>
> Other than gaining assurance in the real-time behaviour, there's a 
> related problem of gaining approval from your regulator for the GC and 
> runtime library components.
>
>  - Rod
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190910/5c3b46f6/attachment.html>