OSDev.org

As you all know, there is no CPU feature for multitasking in real mode. Using a timer, or Cooperative multitasking (Your program model is a loop, with a call at the end to the task switcher) this can be accomplished. After completing writing my disk system, i had thought up how i would get my own version to work.

My Last OS project had a simple process model. So i wanted something a little more interesting.
So i decided something like this..



The kernel process is its own tasking model, cooperatively multitasking through drivers as if they are processes along with the kernel itself. Since cooperative, each driver will have to have a program loop.

From the timer, it preemptively multitasks, running the kernel and many other programs.

What do you all think of this design, any comments, or additions are welcomed.


Edit: if the image confuses you in anyway, I am willing to draw something more clear.
If you can't read, i'm afraid i can't help you with that.

???

Real mode is just like any architecture, only voided of protection mechanisms. Any theory related to scheduling works exactly the same in real mode as it does in protected mode.

In other words, your point?

Combuster wrote:In other words, your point?

VolTeK wrote:What do you all think of this design, any comments, or additions are welcomed.

Was what i wanted

Edit: if the image confuses you in anyway, I am willing to draw something more clear.

Why not lead with the clearer image? I have no idea what I'm currently looking at.

~JL

From what I see you are relying on the system timer to switch between the kernel and various userspaces and back again? Generally for a monolithic kernel, pre-emptive multitasking is between processes only (with the caveat of background kernel worker threads) and the processes then call into the kernel for various services which then return. You can choose whether the task is pre-emptible when it is in the kernel or not.

Exactly what do you expect the kernel to be doing when it is running its own timeslice and then co-operatively multitasking between threads? Are these background threads (e.g. memory/process clean-up) or are they responding to the requests of the processes (e.g. file/network access) in a microkernel fashion?

Regards,
John.

If I understand correctly, the whole kernel and drivers are single process that chains with fiber instead of threads.

I suggest to decouple the task switching mechanism(context switch code) with the triggers(PIT) - That way a process or the kernel itself may give up its time-slice before the deadline comes.

bluemoon wrote:If I understand correctly, the whole kernel and drivers are single process that chains with fiber instead of threads.

That's exactly what it is, i never knew fiber existed

bluemoon wrote:I suggest to decouple the task switching mechanism(context switch code) with the triggers(PIT) - That way a process or the kernel itself may give up its time-slice before the deadline comes.

Maybe i misunderstood what you mean't but the Highest level task switcher will time processes and make sure the kernel is called between every other process. (Kernel 1) 1 2 1 3 1 4. This in my eyes is not a priority thread though. That just means its called conveniently enough. If a process were to want more priority, it will be executed N more times (N being the priority amount, 1 low, 2 med, 3 high). The kernel is still called in between each time. In other words, process time is monitored, but i want it to stay as "the kernel is called the most".


With the lowest level task switcher (kernel and drivers) each driver is a fiber (a mini-process? within a kernel world?) the kernel being its own process, the drivers being like processes, only being fibers within the kernel process.

The task of drivers (Right now) for example Floppy.sys only relays messages back to the kernel job list to tell it, a floppy disk change has been detected. So the value that held [Drive.Media] would be xor'd with itself. This CAN be a problem if the value was set wrong the first time then:

-There wasn't media, when there was

*Disk Was Ejected* XOR

-There is media, when there really wasn't.

This scenario is insured to stay corrected as the value is set upon device registration. In other words, the kernel uses a job list, and drivers right now are just workers running around telling data about their hard ware they are monitoring. If you have any suggestions for how much more a driver should work please tell me.

What I suggested is a mechanism for kernel or application process to give up its time before PIT trigger.
You don't want to wait(or even worst, busy-wait) for PIT when there is nothing to do within current process(including kernel itself).

bluemoon wrote:You don't want to wait

I don't understand what you mean, no process would wait. It would execute until it was task switched. Nothing should wait

We have a communication error here, but I'll try to describe the case more clear.

Imagine there is 3 application, named A, B, C and one kernel K running in a single core CPU.
For plain time sharing scheduling as you proposed, we suppose the PIT run at 1KHz

We further assume the following scenario as one of the possible case:
A: A shell
B: Alarm clock
C: Prime number crusher

So, A get scheduled and it will run for 1ms, however A is a waiting for user input, without any mechanism to give up (yield) its time slice the machine is doing nothing until next scheduling.
Then at T=1ms, K got scheduled, it loops thru' all the driver but it finished quickly since there is not much events, without any mechanism to give up (yield) its time slice the machine is doing nothing until next scheduling.
At T=2ms, B got scheduled, it check for current time and its not alarm time, without any mechanism to give up (yield) its time slice the machine is doing nothing until next scheduling.
At T=3ms, K got scheduled, it loops thru' all the driver but it finished quickly since there is not much events, without any mechanism to give up (yield) its time slice the machine is doing nothing until next scheduling.
At T=4ms, C got scheduled, it used up all its time slice for calculation.

As you can see, the machine is running with less than 1/6 of its power to do useful work, the more process there are, the less efficient the machine.


Anyway, when it comes to scheduling, Brendan describe it way better than I.

I see what you mean (And if it seems like i don't PM me) for now i feel what everyone does with their slice of time does not matter. For now that is.

VolTeK wrote:For now that is.

The problem being that it is very difficult to change it later. You basically have a dumb design that for some reason you're not willing to change, and which will be diffiicult to change in the future when you're really stuck with it. Better change it now.


JAL