List of unique features of SC RTOS which makes it difficult to implement an API.
Accepted per 2016-09-26.
Comment 6 Daniel Herring 2016-10-31 13:58:37 PDT
Feature: ARINC 653 Time Partitioning & Hard Time Partitioning
The ARINC 653 specification defines time partitioning where a process has control of the CPU for a specific amount of time and then the operating system will do a context switch even if the application is not done executing. This can be a problem for APIs which internally use locking mechanisms because the API has no understanding of when the time partition is ending. As such it is possible that one process locks a mutex/semaphore/... then is context switched and prevents all other processes from using that locked object. This differs from the regular lock contention issue in that the Time Partitioning scheduler will not allow the process holding the lock to run, while a priority preemptive scheduler may wake up the process holding the lock to let it unlock.
Applicable to:
DDC-I - DeOS
Green Hills - Integrity
Green Hills - Integrity 178B
Lynx - LynxOS 178
Wind River - VxWorks 653
irudkin
commented
7 years ago
Erik Noreke 2015-10-23 05:44:43 PDT
Create a list of real time safety critical operating systems for group reference.
Comment 1 Erik Noreke 2015-10-23 05:45:27 PDT
Per Houston F2F - Assigned to Erik
Comment 2 Erik Noreke 2015-11-13 12:05:36 PST
SafeRTOS INTEGRITY-178B RTOS
Comment 3 Greg Szober 2015-11-16 06:29:23 PST
Wind River - VxWorks 653 Wind River - VxWorks Cert SysGo - PikeOS Lynx - LynxOS QNX - QNX DDC-I - DeOS ExpressLogic - ThreadX
Comment 4 Erik Noreke 2015-12-02 12:34:48 PST
Green Hills Software ThreadX RTOS - Express Logic Nucleus RTOS - Mentor Graphics
Comment 5 Erik Noreke 2016-09-26 07:56:08 PDT
List of unique features of SC RTOS which makes it difficult to implement an API.
Accepted per 2016-09-26.
Comment 6 Daniel Herring 2016-10-31 13:58:37 PDT
Feature: ARINC 653 Time Partitioning & Hard Time Partitioning The ARINC 653 specification defines time partitioning where a process has control of the CPU for a specific amount of time and then the operating system will do a context switch even if the application is not done executing. This can be a problem for APIs which internally use locking mechanisms because the API has no understanding of when the time partition is ending. As such it is possible that one process locks a mutex/semaphore/... then is context switched and prevents all other processes from using that locked object. This differs from the regular lock contention issue in that the Time Partitioning scheduler will not allow the process holding the lock to run, while a priority preemptive scheduler may wake up the process holding the lock to let it unlock. Applicable to: DDC-I - DeOS Green Hills - Integrity Green Hills - Integrity 178B Lynx - LynxOS 178 Wind River - VxWorks 653