OSDev.org

i have learned recently about the project Oberon. an os developped on 1986 using the OO paradigm. in a first time i was surprised by its design: talking about viewers (windows) and mouse (messages) while stille in the low stages is not usual. but i was specially interested by the tasking sheme.

Actually all production oses use the preemptive sheme : influenced probably bu the unix design. the traditional argument is that an application can not block the entire system (if it is runs an infinite loop for example). However, this implies task switching on closely spacing times. the system become more slower.

The Oberon os is designed with "user interaction in mind". THE USER SHEDULES ITS PROCESS. by choosing (clicking) a viewer (window) the system activates this window. the atomic action is called Command: this is equivalent to GUI message handler. the system either is executing a command or running an infinite loop fetching events from "event sources" and sendong them to the active viewer. by making "Command" the atomic unit of execution: it eliminates most complexity from the task sheduler and simplifies (or eliminates) synchronisation issues. the system also become more responsive because task switching does not occure N times per seconds. .

i think this kind of cooperative multitasking can be used without the risk to make the system blocked by an application that may not "yeild" because X86 machines are interruptibles. and in response to user inputs the system can deactivates the blocking task and switch to the desired task.

While the point you make is not entirely void, I want to point you to the following:

even if you incorporate a preemptive scheme (Drivers have to preempt services and services have to preempt user processes or other services - well, and user processes in priority round robin are preempted as soon as their timeslice is used up), you will find, that your user tasks block whilst waiting for IO mostatime.

Round robin timeslice or other timeslice methods are to make sure, that despite one or two instances of cpu intense programs others in the level round robin get their share of cpu time.

I reckon mostatime on a preemptive multitasker you'll encounter cooperative multitasking: yield(), signal(), proberen(), verheugen(), send(), receive(). JUst to say: user tasks are waiting on some events either from system or an other user task/service.

Hope this clears things up a bit.

stay safe

well, i shall admit i'm not a oberon-guru ... i cannot tell, for instance if the "command" is supposed to run to completion in a given time.

yet i'd be interrested if you could tell how oberon could keep the GUI responsive (and e.g. be used to browse documents) while you're waiting for a "make kernel" to complete in the background.

Cooperative multitasking systems in general are good when programs cooperate, which usually means your programs may not be misbehaving, but except in specific environment, you don't have the control on what programs are running...

Consider cooperative-only multitasking: A thread only ever yields control when it does so explicitly on it's own.

Then consider:
As your program never yields control, there is nothing you can do to stop it. Ctrl-C? Keyboard driver (and shell) are waiting for the program to yield control. Clicking on the task manager icon? Mouse driver is waiting for the program to yield control. After looking at your hanging shell for a couple of minutes, you reach for the "reboot" button.

From there on, it's all a matter of compromise. If the mouse is moved, or keys are pressed on the keyboard, you have to interrupt program flow to handle the event. Same for network, disk DMA finishing, or other port interrupts. Note that many devices do not handle it at all gracefully if their interrupts are not handled in time. All this is superimposed on your design by the hardware.

And once you have implemented all this, adding a reschedule() when a certain time slice is exceeded is merely an afterthought.

From comp.lang.oberon:

That doesn't seem like much
today when most modern OS's are
multithreaded, but back in 1994 when Oberon/F
was first released most of the world was
using Windows 3.1 which only had
cooperative multitasking.


Oberon/F uses cooperative multitasking
also, but it's a scheme known as
"single process multitasking". Basically
you take the routine you want processed
in the background and break it down to
a single repeated "step". Then this step
is put on a queue and gets called
repeatedly along with other steps or
"actions". (Oberon System 3 and V4
call them "tasks").


The beauty of SPM is that you never
have to worry about saving the "state"
of the task as you do in preemptive
multitasking and in MOST cooperative
multitasking schemes.


Active Oberon (BlueBottle) uses a
preemptive multitasking scheme.

As for cooperative-MT operating systems... we had a couple of those.

MacOS added cooperative MT in v7, and some partial preemtive MT in v8. AFAIK, it was not until v10 that they added full preemption.

Windows 3.11 was the last of the cooperative-MT Windows'. NT and 95 were fully preemtive (*cough*).

You might agree that neither MacOS v7 nor Win3.11 set any records for responsiveness. There's some reason they rebored those two to do preemption (like Unix, RiscOS, AmigaOS and others did right from the start).

seems the Oberon history repeats what i already knew: any system that is cooperative-oriented will once suffer from being cooperative and will have to evolve to a preemptive system.

And *that* evolution will be a nightmare for all the developers involved ... in a hobby OS, that might mean the end of the project.

The only exception i can see is "embedded" OSes where the OS is barely more than a hardware-abstraction library and when the application might be distributed, but is designed by a single team and glued together with the OS in some firmware. Dvd player software, gamebox, etc. could work perfectly fine with cooperative multitasking because in this very case, you have control on everything that runs in the system ...

And no, having the option to "forcely kill a misbehaving program that doesn't yield" is not a solution because this program might have locked resources that you won't be able to unlock properly ... so you just get a breath of fresh air for a couple of minutes but your system will eventually fail afterwards.

so the traditional problem is "misbehaving program that doesn't yield". i'm thinking : instead of waiting until the user program yeild the cpu control, the sheduler can, in response to other interrupt sources than the timer, switch to another task. i'm especially thiniking on user inputs. so even if the program runs an infinite loop, the system still handles interrupts (example: clicking a mouse on a window activates the corresponding task), this implies adding mouse/keyboard (for example)control at very low stage so that can be used by the sheduler.

now the problem is effectively background tasks, especially kernel tasks. because this tasks doesnt interact with the user the only way to shedule them is by the timer interrupt. and the only to guarantee they receive their execution time is to make time slice so we alaways back to preemption >:(.

in some manner, preemptive MT at user level is more like cooperative MT. when the user activates a user prog. the dactivated prog is blocked (=yeild control) and the new prog receives input msgs (and receive control).

Well... I think I start to see what your aim is, but I don't think coop MT is the road.

You want to avoid wasting resources (clock cycles) on any other program than the one the user currently has in focus, right?

The usual approach here is to assign the "current" application a higher priority in the preemptive scheduler. Let's face it, with the hardware interrupts described above (including user input), an application is preempted pretty frequently, anyway - so the timer interrupt is not that important anymore, anyhow. If you increase the priority, you make sure the same in-focus app gets another timeslice right away unless something really important is going on elsewhere, you should be close to your ideal.

However, two things:

One - apps that are important to the user, but running in the background. If I start my DVD application to burn a DVD, I might want to write an e-mail while the DVD app finishes its task. I wouldn't like it if my mail program would starve the DVD writer for resources, ruining the DVD...

Two - the basic assumption is that the user wants "instant" feedback by the app he is using right now. The problem is that virtually all "user-interfacing" applications spend 99% of their time idle, waiting for input. Usually, you get a much more "snappy" feeling if you make the in-focus app wait for a certain input event, and in the meantime spend your resources elsewhere instead of busy-waiting for the user. And what's more, what makes Windows machines feel "slow" is not the time they take to finish a task, but the time they take to acknowledge your input. If a button goes "down" the very instant you press it, you don't fret about a two-second execution time as much as you fret about it when it takes one second to even acknowledge your click, and then takes another second to complete.

rootel77 wrote: instead of waiting until the user program yeild the cpu control, the sheduler can, in response to other interrupt sources than the timer, switch to another task.

As soon as you take the CPU from a task as the result of an IRQ, you're doing preemptive multitasking. Preempting tasks do not necessarily implies that tasks are preempted every X microseconds due to a timing interrupt, it just organizes things such as tasks can be taken the CPU at any time, regardless of what they do right now.