questions on the internal of task switching (i really need)

[ITchimp]

I am reading james molloy's tutorial on kernel development, currently at the multi-tasking section.
[url]http://www.jamesmolloy.co.uk/tutorial_html/9.-Multitasking.html
[/url]

he mentioned that there are two states after read_eip() exits

1. we just called read_eip and it returned the instruction pointer

2. we just switched task, the execution starts at just after read_eip function...


my question is on the second bullet...

the task switch is called in the timer interrupt routine... it is the only entry point for doing scheduling...

how is 2 possible because that would imply that we are in a interrupt routine while being interrupted ...so
we are switching tasks while switching tasks?

how does that make sense?

[Octocontrabass]

That tutorial spawns tasks using a method similar to fork. The instruction pointer returned by read_eip() is placed in the task struct, which means the new task will start by returning from that call to read_eip().

Note that while it is possible to make this work, the way James Molloy's tutorial implements it is completely insane. Instead of trying to create fork() for the kernel, it's usually a better idea to come up with reasonable values to put into the registers yourself, in order to start the new kernel thread at an appropriate location with an appropriate stack pointer.

Tutorials are usually wrong to varying degrees, so it's best to avoid them when writing an OS.

[ITchimp]

I am not at a level where I can discern the insanity... I just need some one to help me further my understanding
of multitasking code

[8infy]

I am not at a level where I can discern the insanity... I just need some one to help me further my understanding
of multitasking code

Here are a few better links:
http://www.brokenthorn.com/Resources/OSDev24.html
https://wiki.osdev.org/Brendan%27s_Mult ... g_Tutorial

[ITchimp]

Thanks, I am still looking for explanation as to why the 2nd case can possibly happen... the only way to call
task_switch is in ISR... but the 2nd case in his code imply that while it is in ISR that it is interrupted again...

I really need someone to help me on that!!!!

[iansjack]

the only way to call task_switch is in ISR...

A task switch is not only the result of a hardware interrupt.

[ITchimp]

but in his code it appears to be the only point context switch could happen...

[iansjack]

From that tutorial:

That timeslice is normally ended by a timer interrupt which calls the scheduler.

It should be noted that in more advanced operating systems a process' timeslice will normally also be terminated when it performs a synchronous I/O operation, and in such operating systems (all but the most trivial) this is the normal case.

(My bold)

Please note that I am not recommending this as a good tutorial.

[ITchimp]

Iansjack, you are my personal hero. I have to understand the second case and why it happens....I have to know!!!!

[nexos]

So basically, after we switch tasks it would useless to context swap as the state is already there. By execution he means execution of the next task. I still don't clearly understand what he means, however. His multitasking code is complicated at best.

[iansjack]

It's really the difference between a switch triggered by the timer (a hardware interrupt), or those triggered by the code itself such as when waiting for a response from a (relatively) slow device. In such a case the task will ask to be blocked and then a voluntary task switch occurs. The former can happen at any time, anywhere in the kernel code (where interrupts are not disabled); the latter only happens at well defined, fixed points in the code - almost always, if not always, outside any hardware interrupt handler.

As has been mentioned previously, you need to be aware of the difference between hardware interrupts and software (so-called) interrupts; the latter are not really interrupts.

[Octocontrabass]

Thanks, I am still looking for explanation as to why the 2nd case can possibly happen... the only way to call
task_switch is in ISR... but the 2nd case in his code imply that while it is in ISR that it is interrupted again...

I really need someone to help me on that!!!!

I already explained it.

The instruction pointer returned by read_eip() is placed in the task struct, which means the new task will start by returning from that call to read_eip().

That is the location James Molloy selected as the entry point for all new tasks. Any time you switch to a new task that hasn't been executed yet, it will begin at the entry point, even if it's impossible for running tasks to be interrupted at that point.

[ITchimp]

he uses EAX register to hold a dummy value 0x12345;

What if the another process (from which the current one is switched to) manipulated the EAX register and
set it to another value other than 0x12345... then James Molloy's code could malfunction.. is it possible for the
scenario to happen?

The remedy I think.... is to push all registers on stack before task switch and restore the registers back.. but I am
looking at some tutorial to figure out... any suggestion or alternative way to software task switching is hugely
welcome!

[Octacone]

The solution is quite simple. Don’t use his old, outdated, buggy as hell tutorial at all. Write everything yourself. We’ll be glad to answer any of the questions you might have. Trust me, once you understand how it works internally, writing the actual code is a joke. You shouldn’t rely on any tutorials for code, only for theoretical knowledge that might be mediocre at best. His tutorials are very outdated and full of bugs, please don’t use them.