Veserv has correctly restated what I meant by my original comment (which I still stand by). In my first reply, I used a mutex as an example for a contended resource. A cooperative multitasking system just extends "contended resource" to include the CPU.
Just like you need to make sure you don't hold a critical lock for too long in a preemptive multitasking system, you need to make sure you don't run on the CPU for too long in a cooperative multitasking system.
[replying to GP so as to not fork this thread too much]
> 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.
Sure it can: just poll for preemption every N usecs. You can even statically analyze the assembly code to calculate the maximum number of clock cycles between two points where you poll for preemption (in the event that your microcontroller has caches, you will want to use writethrough caching to help with this analysis).
> 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).
This was the whole point of that example. A realtime scheduler only guarantees that a thread gets the CPU time it is promised. CPI time is one of (potentially many) contended resources in a multitasking system. It is so helpful because all tasks will be contending for CPU time and there are few other resources for which this is true (memory bandwidth, particularly on SMP systems immediately comes to mind).
To be clear: I like realtime schedulers. The are great and simplify many things; the analyses of tasks that only contend for CPU are greatly simplified by them.
Just like you need to make sure you don't hold a critical lock for too long in a preemptive multitasking system, you need to make sure you don't run on the CPU for too long in a cooperative multitasking system.
[replying to GP so as to not fork this thread too much]
> 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.
Sure it can: just poll for preemption every N usecs. You can even statically analyze the assembly code to calculate the maximum number of clock cycles between two points where you poll for preemption (in the event that your microcontroller has caches, you will want to use writethrough caching to help with this analysis).
> 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).
This was the whole point of that example. A realtime scheduler only guarantees that a thread gets the CPU time it is promised. CPI time is one of (potentially many) contended resources in a multitasking system. It is so helpful because all tasks will be contending for CPU time and there are few other resources for which this is true (memory bandwidth, particularly on SMP systems immediately comes to mind).
To be clear: I like realtime schedulers. The are great and simplify many things; the analyses of tasks that only contend for CPU are greatly simplified by them.