OSDev.org

[moved here]It seems that this topic should be here...

Hi all.

These days I've just thought up something random about multitasking while I'm just imeplementing the traditional one.

Let's say that we have procedure A,B,C... and main(They are in different programs and loaded into different processes at runtime) and when developing the programs we don't know how many procedure like A,B and C will be created(they're all different). At runtime main calls A,B and C... quite frequently(at a fixed and very high frequency or even execute one call immediately after another) and A,B and C... should be called at the same time(in a logical perspect) if they're called(i.e. they're a combination but we can't determine them when compiling because maybe some more may join them). Each time they're called together they form something like a frame,just like the refresh of your screen.It's like a frame because they are together and produced frequently.

For example(just an example,I'm not professional in this and don't want to discuss details about this) in a 3D engine when a object is pushed its position will be influenced.Then immediately the position change will influence its lighting and the lighting shall be recalculated(updated) at once.They may depend on one another and even each other(for example F=Bvq).

So the each process among A,B and C etc is just like one subsystem in the 3D engine.The engine give every stage many objects and a common time line.The time line makes events happening at different times synchronised respectively.When other facters are added to the engine(as new processes at loadtime) they can work well with the existing parts of the engine as long as they obey the data structure for each object and the TIME LINE.

We may have other occasions like that:we have several processes in memory all the time to provide frequent services,synchronised with each other. For this reason I want to add a multitasking functionality to my OS.Such as:

INT 0X70 --------process frame(the frame mentioned above) functionality
EAX = 0 ---- create a new frame
EBX = new frame id num.
ECX = time alignment
--------
EAX = 1 ---- add the current process to a frame
--------
EAX = 2 ---- quit from a registered frame
EBX = frame id num.
--------
(activate a frame,stop a frame,discard a frame,etc)......

A frame is a set of process expected to synchronise with each other to form this frame.One frame will be produced only if every member(process) within it executes once.And then comes the next frame,etc.If time alignment is 0,then the frame will be one after another.If not,after one frame is produced,the next won't begin to be produced until the time inteval reaches 0.We can then add a process to a frame to join their synchronisation(in my original idea it will start with the rest at the next new frame after joining).As long as the new process knows the frame id num.,it can join it.(Every process's default frame is itself.But I haven't thought about how to present it.)

And we can have several frames in memory running in thier own time line.We can even join 2 frames together to let them share 1 time line.With the help of time line,it would be a little easier to understand and control the execution trace.We can even use that to locate processes.

Maybe I don't express the idea clearly.But comments according to your understanding are welcomed.Thanks.

[edit]Even if you don't want to execute the processes so frequently,the time line can also bring convenience(I'm not quite shure about this).

imo, what you are talking about is a heavy process or thread client server model ie. one with many of them working in harmony.

I have a few questions here -

1. How would you schedule the tasks? Only with the timelines?
2. How do you try to ensure fair processor time allottment? (not expecting real-time behaviour). things like ageing and priorities? or do you anticipate burst times?
3. How can you prove processor utilization? if i've not mistaken, frames might run empty, which can be the case if atlest one of the processes enrolled in the frame can not run at the moment because of some heavenly reason? Moreover, do you plan to prematurely terminate an empty running frame to satisfy interrupts, or other high priority processes that get ready (maybe because of sleep time over)?
4. What is the advantage that you propose?


Just a different thought - have you seen the design of Singularity(Microsoft)? They have so called 'channels' which obey 'contracts'.

Could we incorporate some kind of contracts in here?

First I want to say sorry because I didn't express it clearly or in detail.
And something has just changed in my mind.

The original purpose is that I want to add an easier and more uniform interface for process synchronisation and scheduling to my OS. It's based on a set of time expression methods. The situation mentioned above is just one case of them,and as you've said, it's like C/S model but it's very regular(there may be bursts only within a frame). But the timeline and the frame above will be used in the entire interface.

The timeline is generally used to locate a time point(for a certain event). Creating a timeline is creating a new relative time point. If a process join a timeline, it will later use this one to specify a time point relatively. The frame is based on the timeline.From a simplified view, it determines how many times the process(es) would execute continuously. After a frame is produced(by executing all the processes within it once), the timeline which the frame is based on will be reset and the next frame comes. Adding the frame is just to meet the need of some applications and it doesn't have anything in concept to affect the timeline. Both the timeline and the frame are visible to user applications, with different usages. Users can specify a time point with both the timeline and the frame. For example, at the 17th ms within the 3rd frame of frame set A, or at the 255th ms within the current frame, or even right after a certain event(if you don't know the absolute time point), etc. But users can only create frames, not timelines.

Some(not all) expected system calls listed here may help to understand:
1.Creating a frame set. Parameters: 1)the frame set id 2)how many frames within it(specify INFINITE to set up a TSR or 1 for a single timeline 3)the time point to create this frame set 4)time alignment
2.Create a process(after creating a process and before its execution, it must join a frame). Parameters: 1)all the other things need to create a process 2)the id of the frame set to join 3)the time to start it

Now prashant, thanks for your attention. Err, sharp questions indeed...

1.I'll use both the timelines and traditional scheduling mechanisms. The timelines are visible to users while the latter one won't. The latter one is used for general purposes as all of you do and it's can be used both within a frame and between different frames.
2.Existing one would fit.
3.You mean the case where all the processes within a frame are blocked? Do you notice the time alignment option in the system call? If no deadlocks occur, all of them must resume later. So we have 2 alternative: 1)If the time is out(longer than the time alignment), discard the current frame and start the next one(this is generally not expected...) 2)If the time is out, once the frame resumes it will still execute with the time alignment omitted. I prefer the 2nd one.
4.1)To simplify the interface for synchronisation and process scheduling 2)to improve the consistency.(Seeing scattered wait() calls and so on in many process is annoying, isn't it?)

I've heard of Singularity and known its aims very briefly. I don't know much about its detailed implementation. Would you say something more about the channel and the contract?

Regards...