4 ms·

A real time operating system can, by definition, not be cooperative. Definitely not a hard one and a soft one most likely not either, simply because it can not

A real time operating system can, by definition, not be cooperative. Definitely not a hard one and a soft one most likely not either, simply because it can not guarantee that it will process the interrupt quickly enough to be qualified as RTOS. https://en.wikipedia.org/wiki/Real-time_operating_system https://en.wikipedia.org/wiki/Real-time_operating_system When you set a timer, which stops the running task to switch "to somewhere else", then it's not cooperative. Can you elaborate?

addaon 4y ago
A real time system can be cooperative. A real time operating system can use pre-emption to achieve bounded latency. A real time system that does not use pre-emption can use other mechanisms -- including a combination of analytical bounding of task run-times and static cooperative scheduling -- to achieve bounded latency. The latter system can be enhanced by enforcing the analytical bounds, making it somewhat robust to errors in analysis. One can argue that this enforcement makes the system non-cooperative, it's certainly not full pre-emption with all the costs and benefits that go with. As an example of such a system, consider a bare metal BLDC motor driver. You may statically schedule a sequence of tasks -- read current sensors, read commands, adjust PWM hardware registers, read temperature sensors, change state on temperature error, loop. Suppose that the 'read temperature sensors' task can fail to meet its analytic time budget because the I2C hardware can get into a weird state and just not return. (Suppose further that this isn't hypothetical...) Then having a kill-and-reset-on-timeout feature for the temperature sensor task is an obvious and reasonable workaround to give an improved system. That feature can be added to the temperature sensor task; or, it can be added as a general feature to the round robin scheduler in the way I described. Hope that's a helpful description of what I was trying to explain! I'm not in any way saying this is a general solution or a universal replacement for a real RTOS; rather that it's a pattern I've ended up re-deriving a time or two that I find interesting.
- anonymousiam 4y ago
  Heh. I2C was part of what I was doing on the aforementioned MSP430 OS. I ended up breaking up all the I2C stuff into parts of a state machine (I think I ended up with six states), and ran it in the background as the lowest priority main loop.
anonymousiam 4y ago
The MSP430 RTOS I wrote was real-time and cooperative, with the caveat that it was application specific, and no task would ever take more than one millisecond to complete. I was careful to design all the tasks so they would never exceed the maximum run-time. For the tasks that needed more time, I broke them into several sub-tasks. You said; "When you set a timer, which stops the running task to switch "to somewhere else", then it's not cooperative." You are correct. The OS does not require the cooperation of the task in order to suspend it and start/resume a different task. A non-cooperative OS does not require the task to either make a system call (such as waiting on I/O) or to finish. It will preempt the running task according to the scheduler rules. Typically a scheduler will receive periodic interrupts so that it can assess which task should be made active. On real-time systems without much processing headroom, the context switching between tasks can take up a significant percentage of CPU time, which is why I went with cooperative multitasking on the (25MHz) MSP430 micro-controller.

addaon 4y ago

A real time system can be cooperative. A real time operating system can use pre-emption to achieve bounded latency. A real time system that does not use pre-emption can use other mechanisms -- including a combination of analytical bounding of task run-times and static cooperative scheduling -- to achieve bounded latency. The latter system can be enhanced by enforcing the analytical bounds, making it somewhat robust to errors in analysis. One can argue that this enforcement makes the system non-cooperative, it's certainly not full pre-emption with all the costs and benefits that go with. As an example of such a system, consider a bare metal BLDC motor driver. You may statically schedule a sequence of tasks -- read current sensors, read commands, adjust PWM hardware registers, read temperature sensors, change state on temperature error, loop. Suppose that the 'read temperature sensors' task can fail to meet its analytic time budget because the I2C hardware can get into a weird state and just not return. (Suppose further that this isn't hypothetical...) Then having a kill-and-reset-on-timeout feature for the temperature sensor task is an obvious and reasonable workaround to give an improved system. That feature can be added to the temperature sensor task; or, it can be added as a general feature to the round robin scheduler in the way I described. Hope that's a helpful description of what I was trying to explain! I'm not in any way saying this is a general solution or a universal replacement for a real RTOS; rather that it's a pattern I've ended up re-deriving a time or two that I find interesting.

anonymousiam 4y ago
Heh. I2C was part of what I was doing on the aforementioned MSP430 OS. I ended up breaking up all the I2C stuff into parts of a state machine (I think I ended up with six states), and ran it in the background as the lowest priority main loop.

anonymousiam 4y ago

The MSP430 RTOS I wrote was real-time and cooperative, with the caveat that it was application specific, and no task would ever take more than one millisecond to complete. I was careful to design all the tasks so they would never exceed the maximum run-time. For the tasks that needed more time, I broke them into several sub-tasks. You said; "When you set a timer, which stops the running task to switch "to somewhere else", then it's not cooperative." You are correct. The OS does not require the cooperation of the task in order to suspend it and start/resume a different task. A non-cooperative OS does not require the task to either make a system call (such as waiting on I/O) or to finish. It will preempt the running task according to the scheduler rules. Typically a scheduler will receive periodic interrupts so that it can assess which task should be made active. On real-time systems without much processing headroom, the context switching between tasks can take up a significant percentage of CPU time, which is why I went with cooperative multitasking on the (25MHz) MSP430 micro-controller.