3 ms·

> 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 cooperat

> 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.

PaulDavisThe1st 3y ago
A kernel (because that's where interrupt handlers are located) can ensure that a thread is scheduled with N usecs of when it "ought to be" (which could be based on some sort of time allocation algorithm, or simple priorities or whatever other scheme may be in use. The kernel can say "oh look, it's been N usecs, let's check who is running and who is ready to run ... hey, time for Thread 2 to run". This is preemptive scheduling. No cooperative scheduling system can ensure this. Your example involves poorly designed code, which is not the responsibility of the scheduler. Its job is just to make sure that threads run when they "ought to" - it cannot protect against priority inversions in user space and ensure that RT guarantees are met (pick 1, and even then, you lose).
- aidenn0 3y ago
  > A kernel (because that's where interrupt handlers are located).. Thought I would pull this one phrase out to demonstrate how we are clearly talking about different systems. For many embedded control systems, I would not say "the interrupt handlers are located in the kernel." On processors that have the distinction, interrupt handlers typically run in Supervisor mode (What the x86 calls "Ring 0"), but it's entirely possible that 100% of the code will run in Supervisor mode. When the kernel provides preemptive scheduling, it may handle a single interrupt (a timer); alternatively the kernel doesn't handle any interrupts, but instead provides an API call that application developer(s) must invoke for entering the scheduler. Many things that are called an "RTOS" in the embedded world would be called a "threading library" in the desktop world.
- Veserv 3y ago
  You two are talking past each other. They are saying that a real time application requires a transitive closure analysis of all cooperating partners to verify if service can be guaranteed. A cooperative scheduler requires you to extend the transitive closure to all code in the system. For a critical appliance where the appliance as a whole needs to guarantee service, this means your transitive closure already encompasses all code in the system, so you are not losing too much. The advantage of preemptive scheduling is that it allows you to subdivide your applications so that you do not need to analyze everything in the system. You can restrict yourself to only considering direct and intentional interaction. This provides modularity advantages and allows you to provide guarantees to sub-components even in the presence of errors or malicious behavior in other components. However, if you are doing whole system analysis anyways and the systems are simple enough to be tractable to analyze without decomposition, then a cooperative scheduler is adequate to ensure real time performance.
  - PaulDavisThe1st 3y ago
    The original claim was: > On a preemptive OS, all multitasking with (non-CPU) contended resources is, to a certain extent, cooperative This just isn't correct.

PaulDavisThe1st 3y ago

A kernel (because that's where interrupt handlers are located) can ensure that a thread is scheduled with N usecs of when it "ought to be" (which could be based on some sort of time allocation algorithm, or simple priorities or whatever other scheme may be in use. The kernel can say "oh look, it's been N usecs, let's check who is running and who is ready to run ... hey, time for Thread 2 to run". This is preemptive scheduling. No cooperative scheduling system can ensure this. Your example involves poorly designed code, which is not the responsibility of the scheduler. Its job is just to make sure that threads run when they "ought to" - it cannot protect against priority inversions in user space and ensure that RT guarantees are met (pick 1, and even then, you lose).

aidenn0 3y ago
> A kernel (because that's where interrupt handlers are located).. Thought I would pull this one phrase out to demonstrate how we are clearly talking about different systems. For many embedded control systems, I would not say "the interrupt handlers are located in the kernel." On processors that have the distinction, interrupt handlers typically run in Supervisor mode (What the x86 calls "Ring 0"), but it's entirely possible that 100% of the code will run in Supervisor mode. When the kernel provides preemptive scheduling, it may handle a single interrupt (a timer); alternatively the kernel doesn't handle any interrupts, but instead provides an API call that application developer(s) must invoke for entering the scheduler. Many things that are called an "RTOS" in the embedded world would be called a "threading library" in the desktop world.
Veserv 3y ago
You two are talking past each other. They are saying that a real time application requires a transitive closure analysis of all cooperating partners to verify if service can be guaranteed. A cooperative scheduler requires you to extend the transitive closure to all code in the system. For a critical appliance where the appliance as a whole needs to guarantee service, this means your transitive closure already encompasses all code in the system, so you are not losing too much. The advantage of preemptive scheduling is that it allows you to subdivide your applications so that you do not need to analyze everything in the system. You can restrict yourself to only considering direct and intentional interaction. This provides modularity advantages and allows you to provide guarantees to sub-components even in the presence of errors or malicious behavior in other components. However, if you are doing whole system analysis anyways and the systems are simple enough to be tractable to analyze without decomposition, then a cooperative scheduler is adequate to ensure real time performance.
- PaulDavisThe1st 3y ago
  The original claim was: > On a preemptive OS, all multitasking with (non-CPU) contended resources is, to a certain extent, cooperative This just isn't correct.