3 ms·

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

by 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.
- Veserv 3y ago
  “with contended resources” is the part you are misinterpreting. They are saying that two applications that contend on a resource must cooperate to operate properly. As they clearly state later: “Making everything cooperative increases the analysis needed because the CPU becomes a manually managed contended resource.” i.e. a cooperative scheduler makes all code contend on the CPU, thus requiring global cooperation. Given that they are providing that case as establishing a new requirement (the CPU becomes a contended resource) they are clearly stating in the preemptive scheduler case that the CPU is not a contended resource and thus no global cooperation is required. Only if they contend on a resource do they need cooperation amongst the contending partys. But again, if you are already doing a whole system analysis anyways, then the benefits are less pronounced.
- aidenn0 3y ago
  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.

by Veserv 3y ago

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.

Veserv 3y ago
“with contended resources” is the part you are misinterpreting. They are saying that two applications that contend on a resource must cooperate to operate properly. As they clearly state later: “Making everything cooperative increases the analysis needed because the CPU becomes a manually managed contended resource.” i.e. a cooperative scheduler makes all code contend on the CPU, thus requiring global cooperation. Given that they are providing that case as establishing a new requirement (the CPU becomes a contended resource) they are clearly stating in the preemptive scheduler case that the CPU is not a contended resource and thus no global cooperation is required. Only if they contend on a resource do they need cooperation amongst the contending partys. But again, if you are already doing a whole system analysis anyways, then the benefits are less pronounced.
aidenn0 3y ago
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.