OSDev.org

Kevin wrote:

alexfru wrote:Also, the CPU wouldn't appreciate many frequent jumps between different parts of different programs.

If anything, you have more switches with a timer interrupt enabled.

I'm not sure about that. To achieve similar responsiveness as with timer interrupts, you'd likely need to break out of loops more frequently than timer interrupts. Add to that all the instructions that load and store state and check the conditions upon which to break a loop.

Timers shouldn't be an issue of responsiveness. For that, you need to handle different events, like a keyboard interrupt, which is still possible in a system with cooperative multitasking. You only get into trouble when your keyboard handler (or whatever input you have) yields before completing its job and it doesn't get regain control soon. Other than that, the only real problem is fair dstribution of processing time when you have multiple CPU intensive processes running concurrently. But for interactive systems with little load, there's no problem at all. Win 3.1 did work okay generally.

Storing and loading the state is the same as with a timer interrupt.

Kevin wrote:Timers shouldn't be an issue of responsiveness.

It's not about timers. It's about doing break/yield inside for/while loops at least as often as in a system that is driven by timer interrupts. You can't do that precisely by writing code by hand and by executing it on a CPU, where many common instructions take varying time to complete (don't forget about CPUs with different and varying speeds (due to overheat and power management; have fun calibrating for that)). So, if you do it less often than in a timer-driven system, you get lower response than in the timer-driven system. If you do it more often, you incur higher overhead than in the timer-driven system. Even if you somehow magically do it at the same rate as in the timer-driven system, you still have the extra overhead in all programs participating in cooperative multitasking (they perform extra checks/jumps to yield at the "right" time (not too often, not too seldom), they have larger and less efficient code because of that as opposed to having all that logic in just one instance in the timer-driven scheduler).

Kevin wrote:For that, you need to handle different events, like a keyboard interrupt, which is still possible in a system with cooperative multitasking. You only get into trouble when your keyboard handler (or whatever input you have) yields before completing its job and it doesn't get regain control soon.

Btw, in this scheme you don't have any automatic priority boosts due to input/events or any other automatic way of (dis)favoring something / adjusting the rate or occurrence of yields. You have to code it manually in the app.

Kevin wrote:Other than that, the only real problem is fair dstribution of processing time when you have multiple CPU intensive processes running concurrently. But for interactive systems with little load, there's no problem at all. Win 3.1 did work okay generally.

As I recall it quite often hung or crashed and DOS appeared far more stable in regular tasks.

Kevin wrote:Storing and loading the state is the same as with a timer interrupt.

If implemented using a call to a dedicated yield routine. Otherwise, your program needs to be designed as a collection of subroutines, called by the OS, e.g. a loop body would be implemented as one such subroutine and every time it's called, it needs to load the state from whatever global variables there are and it needs to store the state back before returning.

alexfru wrote:It's not about timers. It's about doing break/yield inside for/while loops at least as often as in a system that is driven by timer interrupts.

I don't think that's a requirement. The real requirement ist yielding "reasonably often", whatever that may mean.

Btw, in this scheme you don't have any automatic priority boosts due to input/events or any other automatic way of (dis)favoring something / adjusting the rate or occurrence of yields. You have to code it manually in the app.

You can still force a task switch on any other event like hardware interrupts. But yes, if there is no event, there is no such thing as adjusting the rate of yields. A program yields in places where it makes sense for it.

Kevin wrote:Win 3.1 did work okay generally.

As I recall it quite often hung or crashed and DOS appeared far more stable in regular tasks.

Bugs can kill cooperative multitasking easily. News at eleven.

I'm not trying to say that preemptive scheduling doesn't make sense. But with software correctly written for a cooperative environment, it shouldn't actually be needed. In fact, tyndur used to have a #define to suppress timer-based task switches, effectively turning it into a cooperative multitasking OS (mainly to make things more deterministic for easier debugging). If that resulted in a hang, it was a sign for a bug somewhere.

If implemented using a call to a dedicated yield routine. Otherwise, your program needs to be designed as a collection of subroutines, called by the OS, e.g. a loop body would be implemented as one such subroutine and every time it's called, it needs to load the state from whatever global variables there are and it needs to store the state back before returning.

If you like pain, you can do that. Otherwise I would recommend doing the task switches as usual.

It could be useful. A batch processing system (all it does is accept calculations) - the operating system is just listening for keyboard input and write results to the screen, does not require timers at the OS level.