Runtime and determinism

In automotive we are quite triggered by achieving software determinism or in sense of ASIL (Automotive Safety Integrity Level). ASIL is a measurement of integrity, the level of being able to trust given information, for a defined context. Determinism in this sense points to the “operation” (aka event) changing the state and how (/if) we can predict the resulting state under given conditions.

If the resulting state is not controllable we lead to become risky situations (hazards in different level of severity). If we come into such a situation (/state) the considered context was non-deterministic. Lets consider that the context is a specific runtime, manage to execute a given “unit of work”. The unit of work can be a process, a thread, etc. The management capability is often called “execution management”.

On Linux it is represented by e.g., the “systemd” utility – the Linux standard scheduler. The most easiest scheduler is a single process or thread like the Google V8 (i.e. WASM runtime) is. One of the most popular application of Google’s V8 is NodeJS; which is known as single threaded and non blocking I/O runtime. In more depths it internally looks as follows.

Source: https://blog.bitsrc.io/node-js-event-loop-and-multi-threading-e42e5fd16a77

This illustration shows the important part of the execution management, which is provided by libuv https://github.com/libuv. The “event loop” is divided into 4 phases (which might be restricted on a maximum time to run) – the (soft/hard) “real time” thing. The “units of work” are well defined executed, even if multiple threads or processes are spawned. Here the event-callback driven aspect supports.

Source: https://dzone.com/articles/introduction-to-nodejs-3

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *