[SystemSafety] C for OSs
Olwen Morgan
olwen at phaedsys.com
Tue Sep 10 11:19:40 CEST 2019
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>
More information about the systemsafety
mailing list