flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Multitasking and friends......

Author
Thread Post new topic Reply to topic
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
I'm not getting this concept correctly, I guess so..... I read a few pages about Multitasking, and they come with two types Co-operative (I don't bother), and Pre-Emptive, my interest is on the second one. They say each task gets a "timeslice" but my question is how? ....and how is the stack involved in all this?
I'm totally confused about multitasking, if a program's registers are pushed on stack then how does that help while task-switching, I can't imagine a task switch without a CALL or a JMP, both of which require the program to yield() (or RET) which gets me back to co-operative multitasking.

_________________
"Those who can make you believe in absurdities can make you commit atrocities" -- Voltaire https://github.com/Benderx2/R3X
XD
Post 24 Apr 2014, 10:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17624
Location: In your JS exploiting you and your system
revolution
You need an interrupt source. Generally people use a timer of some type.

And if you use protected mode then each ring gets its own private stack. The outgoing task's stack in ring-3 is not touched when the interrupt switches to ring-0. The OS gets control and is then free to choose a different task to start or return back to the interrupted task.
Post 24 Apr 2014, 12:16
View user's profile Send private message Visit poster's website Reply with quote
ManOfSteel



Joined: 02 Feb 2005
Posts: 1154
ManOfSteel
sid123 wrote:
They say each task gets a "timeslice" but my question is how?

Your task manager uses a timer (e.g. the PIT) to divide CPU time into slices, one for each process, and it switches from one process to the next when the time's up.
The task manager's algorithm will tell how long slices should last, whether processes should be given equal time or not, which processes have priority, etc.
It also makes sure the process of task switching itself doesn't consume too much time when there are many tasks (i.e. it minimizes the overhead).

sid123 wrote:
and how is the stack involved in all this?

It saves the context of the task.

sid123 wrote:
if a program's registers are pushed on stack then how does that help while task-switching

If switching to another task loses all of this task's context, then how reliable is your system?

sid123 wrote:
I can't imagine a task switch without a CALL or a JMP, both of which require the program to yield() (or RET) which gets me back to co-operative multitasking.

In cooperative multitasking, processes "cooperate" with each other: one process says it's done and tells the next one to continue from there.
In preemptive multitasking, processes are given specific timeslices by a higher-privileged process (part of the kernel) which switches from one process to another at the end of each slice.
Post 24 Apr 2014, 12:27
View user's profile Send private message Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
Thanks ManofSteel I think my doubts are clear now.
When an IRQ is fired and the interrupt is called the CPU pushes the EIP of the current process on it's stack.
Next the handler pushes the GPRs and the segments of the thread.
After that the CPU switches stack.
Then the handler POPs the registers from the other threads stack.
EIP is still pushed so IRET returns to the EIP of the process whose stack is active.
Now my doubt is that when a process is created it's stack contains nothing, so do I have to push the registers myself while creating a thread?
Post 26 Apr 2014, 00:55
View user's profile Send private message Reply with quote
BAiC



Joined: 22 Mar 2011
Posts: 272
Location: California
BAiC
Quote:
do I have to push the registers myself while creating a thread?

one of the simplest task switchers you could make requires that you initialize the stack address before injecting it into the task list. you only need to write something to the stack region of memory if you define the registers --at the start of the task-- to have a specific value.

you can, however, optimize the task switcher by recording state about the task prior to acting on the other task state (prior to poping stuff off the stack for example).

I have 3 possible states for my tasks at the moment:
1) empty state. this is not only the initial state of a task but it also occurs when a task goes to sleep for whatever reason (this reduces switch penalties for select cases). only RIP and RSP are defined as valid. the processor jumps to the RIP encoded into the task state (rather than a value in the stack) after reading the new task stack pointer into RSP.

2) Integer GPRs only. RSP is encoded in the task state while the RIP address described in (1) is ignored. all of the integer registers are encoded on the stack at the address described by RSP. a simple pop and iret sequence is all that's needed.

3) everything is pushed onto stack, including the Floating Point state. this is the most expensive switch of the 3.

- Stefan

_________________
byte me.
Post 26 Apr 2014, 01:25
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17624
Location: In your JS exploiting you and your system
revolution
sid123 wrote:
When an IRQ is fired and the interrupt is called the CPU pushes the EIP of the current process on it's stack.
If you have a ring change then the stack of the current process is not touched. The incoming stack of the handler is used to store the EIP, EFLAGS and CS values.
Post 27 Apr 2014, 04:32
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.