4 ms·

Can someone clarify this part like I’m 5: > Its design is inspired by purely functional programming paradigm and transputers architecture. > RTOS is implement

Can someone clarify this part like I’m 5: > Its design is inspired by purely functional programming paradigm and transputers architecture. > RTOS is implemented in a form of an executor instead of classic scheduler and doesn't support preemption. Executor runs tasklets, which are fine-grained units of computation, that execute a processing step in a finite amount of time. Transputers seem to be a leftover technology from the 80s, and lack of preemption seems hard to reconcile with real time guarantees?

flyinglizard 3y ago
No preemption makes this an organizer more than an RTOS.
- csdreamer7 3y ago
  Would you please explain more?
  - kimixa 3y ago
    No preemption means that any realtime guarantees are handled by user space, as the kernel relies on that yielding to hit time guarantees. It means it doesn't have to do much of the "difficult" work for a realtime system.
    - aidenn0 3y ago
      On a preemptive OS, all multitasking with (non-CPU) contended resources is, to a certain extent, cooperative. If one task acquires a mutex and then never releases it, no amount of priority-inheritance, highest-locker semantics &c. will fix that. Making everything cooperative increases the analysis needed because the CPU becomes a manually managed contended resource. In addition, while not being preemptive, it sounds like executors are expected to run in bounded time, and the system triggers an event when the time is exceeded. Complete systems, not operating-systems, are realtime. Operating systems can be non-realtime (most general purpose schedulers are completely unsuited for hard realtime systems), but at their best only make the design of realtime systems tractable.
      - PaulDavisThe1st 3y ago
        You are confusing deadlock with scheduling. Sure, deadlock can happen in the absence of "cooperation". And lack of on-time scheduling can happen in a cooperatively scheduled system in the absence of the appropriate cooperation. But scheduling has been considered by most kernel designers to be the responsible of the kernel, not the participants (i.e. preemptively scheduled threads not cooperatively). Even if a thread is going to deadlock as soon as it starts running (again), there is a huge difference between that thread being scheduled at the right time and it not being scheduled. You can fix the former (deadlock) with better coding. You cannot fix the latter without fixing the kernel.
        aidenn0 3y ago
        > You are confusing deadlock with scheduling. Sure, deadlock can happen in the absence of "cooperation". And lack of on-time scheduling can happen in a cooperatively scheduled system in the absence of the appropriate cooperation. I was describing situations much broader than deadlock. The following pseudocode is not deadlock, but nevertheless a failure of cooperation: WaitForMutex(m) DoSomeReallyLongComputation() My point was that the above code in a preemptively scheduled system is as damaging to all tasks that will contend for "m" as this code is in a cooperatively scheduled system: DoSomeReallyLongComputation() > But scheduling has been considered by most kernel designers to be the responsible of the kernel, not the participants (i.e. preemptively scheduled threads not cooperatively). Yes and no. Schedulers tend to have parameters. Realtime systems will rely heavily on those parameters. Those parameters will sometimes even include promises for thread T to not run for more than X amount of time in a period of Y time. > Even if a thread is going to deadlock as soon as it starts running (again), there is a huge difference between that thread being scheduled at the right time and it not being scheduled. You can fix the former (deadlock) with better coding. You cannot fix the latter without fixing the kernel. This is true in a preemptively scheduled kernel. It's kind of tautological that fixing issues with resource X needs to fix the kernel IFF X is managed by the kernel. See also my above paragraph about kernel scheduler parameters. [edit] Just saw who I was replying to. I suspect that you and I have different visions of what a "Real Time System" is, given that I'm thinking industrial control and you're probably thinking audio. There's definitely overlap in theory and discipline, but the hardware and software stacks are rather different.
  - thfuran 3y ago
    What happens when a tasklet take too long?
    - qayxc 3y ago
      I haven't poked into the source code, but usually a QoS event is fired, e.g. "deadline missed". What happens exactly in that case is very application specific.
    - addaon 3y ago
      > What happens when a tasklet take too long? The same thing that happens when 1+1 == 3, or when a task tries to write to memory that it doesn't have permissions for. The static analysis that your system relies on for correct behavior is no longer valid, so a hardware belt-and-suspender mechanism (a schedule overrun timer interrupt, a lockstep core check failure, or an MPU fault, respectively) resets or otherwise safe-states the failed ECU and safety is assured higher up in the system analysis.
qayxc 3y ago
As far as my very limited understanding goes, the transputer reference is simply referring to a highly parallel message-passing system based on message queues, not actual hardware implementations. As for lack of preemption, that's explained by the system not implementing a scheduler. The system "just" implements an executor. An Executor is a component that handles subscriptions (e.g. to interrupts or events/messages), services (both clients and servers), timers, and QoS events (deadline missed, invalid QoS request, task died/unresponsive, etc.), which are implemented as tasks (Aerugo calls them "tasklets") and registered with the executor. • Subscriptions are tasks that subscribe to a topic (of a message). • Service servers are tasks that are invoked when a request from a client is received. • Service clients are tasks that are invoked whenever a response from a server is received. • Timers trigger when a timer expired. • QoS events are fired when a deadline has been missed, a task died/became unresponsive, and other stuff like a QoS request couldn't be met, etc. Aerugo supports a subset of these capabilities, namely message queues (for subscribers/clients and producers/servers), events (IRQs, h/w signals, etc.), and cyclic execution (execute the task n-times or forever). Scheduling - i.e. the priority of things - is handled by the user or built into the Executor itself. For Aerugo the former is the case, so if you need control over priorities and order of task execution, you'd have to implement it on top of it. Now the realtime-part isn't really affected by any of this. It still allows for weaker RT systems. RT just means there's a time constraint on executed tasks. Weaker systems have average runtime guarantees (e.g. a tasks have to finish within a limit on average, i.e. outliers are allowed). Stronger systems are stricter in the sense that tasks always have to finish within the limit. The strongest systems even enforce an exact limit (that is, tasks aren't even allowed to finish sooner - they have to take exactly a given amount of time). Preemption is required if tasks have to be scheduled w.r.t. to different priorities, especiallyy in multi-threaded scenarios. Lack of it means that the executor will never interrupt a running task to execute tasks that take priority - at least from what I understand, which might be wrong.
RossBencina 3y ago
A couple of things of note: Run-to-completion scheduling is a thing in the real-time world. See for example Miro Samek's book Practical UML Statecharts in C++. XMOS makes real-time embedded CPUs supporting task-per-core architecture and hardware message passing. Commonly used in consumer real-time audio hardware, to pick one example. I believe some of the original Transputer people are involved.
toast0 3y ago
>> Executor runs tasklets, [...] that execute a processing step in a finite amount of time. > lack of preemption seems hard to reconcile with real time guarantees? Depends on the requirements and the bounds of the finite time allowed and the enforcement of it. For example, Erlang claims to be soft real-time; it doesn't have preemption, but any function call can result in yielding, and as a functional language there are no loops without calling functions.
- jacquesm 3y ago
  And that works because it is a VM that is executing the instructions. The higher level of the VM can switch threads at will. The measure used is the number of reductions, once a set limit is used or something more urgent crops up a context switch will occur. This functionally indistinguishable from a hardware interrupt for the task that was executing but because it is all done in software you don't actually have that interrupt. It's more as though every reduction has the potential to interrupt a task just like you can expect an interrupt everywhere in a regular stream of machine code for some processor. The nice benefit of the Erlang method is that you can graft this onto a user process without a need for special privilege or exception handling, nothing ever really has to deal with interrupts or the messy aftermath of it, it's much cleaner than an interrupt driven system.

flyinglizard 3y ago

No preemption makes this an organizer more than an RTOS.

csdreamer7 3y ago
Would you please explain more?
- kimixa 3y ago
  No preemption means that any realtime guarantees are handled by user space, as the kernel relies on that yielding to hit time guarantees. It means it doesn't have to do much of the "difficult" work for a realtime system.
  - aidenn0 3y ago
    On a preemptive OS, all multitasking with (non-CPU) contended resources is, to a certain extent, cooperative. If one task acquires a mutex and then never releases it, no amount of priority-inheritance, highest-locker semantics &c. will fix that. Making everything cooperative increases the analysis needed because the CPU becomes a manually managed contended resource. In addition, while not being preemptive, it sounds like executors are expected to run in bounded time, and the system triggers an event when the time is exceeded. Complete systems, not operating-systems, are realtime. Operating systems can be non-realtime (most general purpose schedulers are completely unsuited for hard realtime systems), but at their best only make the design of realtime systems tractable.
    - PaulDavisThe1st 3y ago
      You are confusing deadlock with scheduling. Sure, deadlock can happen in the absence of "cooperation". And lack of on-time scheduling can happen in a cooperatively scheduled system in the absence of the appropriate cooperation. But scheduling has been considered by most kernel designers to be the responsible of the kernel, not the participants (i.e. preemptively scheduled threads not cooperatively). Even if a thread is going to deadlock as soon as it starts running (again), there is a huge difference between that thread being scheduled at the right time and it not being scheduled. You can fix the former (deadlock) with better coding. You cannot fix the latter without fixing the kernel.
      - aidenn0 3y ago
        > You are confusing deadlock with scheduling. Sure, deadlock can happen in the absence of "cooperation". And lack of on-time scheduling can happen in a cooperatively scheduled system in the absence of the appropriate cooperation. I was describing situations much broader than deadlock. The following pseudocode is not deadlock, but nevertheless a failure of cooperation: WaitForMutex(m) DoSomeReallyLongComputation() My point was that the above code in a preemptively scheduled system is as damaging to all tasks that will contend for "m" as this code is in a cooperatively scheduled system: DoSomeReallyLongComputation() > But scheduling has been considered by most kernel designers to be the responsible of the kernel, not the participants (i.e. preemptively scheduled threads not cooperatively). Yes and no. Schedulers tend to have parameters. Realtime systems will rely heavily on those parameters. Those parameters will sometimes even include promises for thread T to not run for more than X amount of time in a period of Y time. > Even if a thread is going to deadlock as soon as it starts running (again), there is a huge difference between that thread being scheduled at the right time and it not being scheduled. You can fix the former (deadlock) with better coding. You cannot fix the latter without fixing the kernel. This is true in a preemptively scheduled kernel. It's kind of tautological that fixing issues with resource X needs to fix the kernel IFF X is managed by the kernel. See also my above paragraph about kernel scheduler parameters. [edit] Just saw who I was replying to. I suspect that you and I have different visions of what a "Real Time System" is, given that I'm thinking industrial control and you're probably thinking audio. There's definitely overlap in theory and discipline, but the hardware and software stacks are rather different.
- thfuran 3y ago
  What happens when a tasklet take too long?
  - qayxc 3y ago
    I haven't poked into the source code, but usually a QoS event is fired, e.g. "deadline missed". What happens exactly in that case is very application specific.
  - addaon 3y ago
    > What happens when a tasklet take too long? The same thing that happens when 1+1 == 3, or when a task tries to write to memory that it doesn't have permissions for. The static analysis that your system relies on for correct behavior is no longer valid, so a hardware belt-and-suspender mechanism (a schedule overrun timer interrupt, a lockstep core check failure, or an MPU fault, respectively) resets or otherwise safe-states the failed ECU and safety is assured higher up in the system analysis.

qayxc 3y ago

As far as my very limited understanding goes, the transputer reference is simply referring to a highly parallel message-passing system based on message queues, not actual hardware implementations. As for lack of preemption, that's explained by the system not implementing a scheduler. The system "just" implements an executor. An Executor is a component that handles subscriptions (e.g. to interrupts or events/messages), services (both clients and servers), timers, and QoS events (deadline missed, invalid QoS request, task died/unresponsive, etc.), which are implemented as tasks (Aerugo calls them "tasklets") and registered with the executor. • Subscriptions are tasks that subscribe to a topic (of a message). • Service servers are tasks that are invoked when a request from a client is received. • Service clients are tasks that are invoked whenever a response from a server is received. • Timers trigger when a timer expired. • QoS events are fired when a deadline has been missed, a task died/became unresponsive, and other stuff like a QoS request couldn't be met, etc. Aerugo supports a subset of these capabilities, namely message queues (for subscribers/clients and producers/servers), events (IRQs, h/w signals, etc.), and cyclic execution (execute the task n-times or forever). Scheduling - i.e. the priority of things - is handled by the user or built into the Executor itself. For Aerugo the former is the case, so if you need control over priorities and order of task execution, you'd have to implement it on top of it. Now the realtime-part isn't really affected by any of this. It still allows for weaker RT systems. RT just means there's a time constraint on executed tasks. Weaker systems have average runtime guarantees (e.g. a tasks have to finish within a limit on average, i.e. outliers are allowed). Stronger systems are stricter in the sense that tasks always have to finish within the limit. The strongest systems even enforce an exact limit (that is, tasks aren't even allowed to finish sooner - they have to take exactly a given amount of time). Preemption is required if tasks have to be scheduled w.r.t. to different priorities, especiallyy in multi-threaded scenarios. Lack of it means that the executor will never interrupt a running task to execute tasks that take priority - at least from what I understand, which might be wrong.

RossBencina 3y ago

A couple of things of note: Run-to-completion scheduling is a thing in the real-time world. See for example Miro Samek's book Practical UML Statecharts in C++. XMOS makes real-time embedded CPUs supporting task-per-core architecture and hardware message passing. Commonly used in consumer real-time audio hardware, to pick one example. I believe some of the original Transputer people are involved.

toast0 3y ago

>> Executor runs tasklets, [...] that execute a processing step in a finite amount of time. > lack of preemption seems hard to reconcile with real time guarantees? Depends on the requirements and the bounds of the finite time allowed and the enforcement of it. For example, Erlang claims to be soft real-time; it doesn't have preemption, but any function call can result in yielding, and as a functional language there are no loops without calling functions.

jacquesm 3y ago
And that works because it is a VM that is executing the instructions. The higher level of the VM can switch threads at will. The measure used is the number of reductions, once a set limit is used or something more urgent crops up a context switch will occur. This functionally indistinguishable from a hardware interrupt for the task that was executing but because it is all done in software you don't actually have that interrupt. It's more as though every reduction has the potential to interrupt a task just like you can expect an interrupt everywhere in a regular stream of machine code for some processor. The nice benefit of the Erlang method is that you can graft this onto a user process without a need for special privilege or exception handling, nothing ever really has to deal with interrupts or the messy aftermath of it, it's much cleaner than an interrupt driven system.