Processes – Guarding Memory Access
Some applications are designed to get ported to various operating systems including simple multithreading executives that do not support any memory protection. Such applications are vulnerable to all sorts of issues introduced by unintended use of memory owned by other blocks of the system.
INtime’s process model supports memory protection of the x86 and x64 CPUs implemented by rings, the MMU and paging unit. Mapping such applications to INtime’s well bounded processes will ease diagnostics during integration of blocks into a system and during deployment of the system in the field because many memory access related issues get trapped by the CPU.
If memory is found changed unintendedly, “who” is easy to answer - always your current process, no code outside this process has access. The question of “how/when” is still hard enough to answer, but eased because code in other processes can’t be the culprit.
Shared memory is the fastest means of sharing data between processes – and a common source of trouble because use of shared memory is completely ruled by custom software designs. Examples of such trouble: the layout of the memory may change and some of the processes using it may not have changed, semaphores coordinating read/write operations may not be used as intended etc. etc.
Guard pages are inserted by INtime’s memory manager to physically separate memory regions.
The “region” or “semaphore” object coordinates mutual exclusion of memory shared between processes.