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.

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.

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).


It saves the context of the task.


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


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.

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?

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

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.