concerning thread context switches

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
icealys
Member
Member
Posts: 60
Joined: Mon Feb 17, 2014 3:54 pm

concerning thread context switches

Post by icealys »

When a thread switches into kernel mode I'm not sure how the kernel saves the thread's registers into the thread control block. How does the kernel mode thread run on the processor and use up the registers at the same time it is copying the user mode thread's registers to the TCB? Wouldn't that be impossible since only one thread can occupy the processor at a time?
User avatar
iansjack
Member
Member
Posts: 4703
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: concerning thread context switches

Post by iansjack »

Come on! It's not that difficult a problem, is it? You have, say, 15 registers that you want to save and you need to write a short assembler routine to do that. Try it.

If you have to change any registers in the routine then you save them first - in fact you've probably pushed some of them to the stack before you even got this far, and the new thread won't be using that stack, so when the thread restores the registers it can pop those ones. You could just save all the registers on the stack, and just save the stack pointer, rather than in a process structure, but that may not be the best solution for other reasons.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: concerning thread context switches

Post by Brendan »

Hi,
icealys wrote:When a thread switches into kernel mode I'm not sure how the kernel saves the thread's registers into the thread control block. How does the kernel mode thread run on the processor and use up the registers at the same time it is copying the user mode thread's registers to the TCB? Wouldn't that be impossible since only one thread can occupy the processor at a time?
Normally the kernel saves the thread's registers on the stack, then does its thing. When a task switch occurs the kernel may just leave the thread's registers on the stack and switch stacks (typical if there's one kernel stack per thread) or could copy the thread's registers into a TCB (typical if there's one kernel stack per CPU).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
icealys
Member
Member
Posts: 60
Joined: Mon Feb 17, 2014 3:54 pm

Re: concerning thread context switches

Post by icealys »

yeah i was just wondering how the kernel actually saves the registers...meaning...how the registers stay frozen in a certain state and then the kernel somehow runs on the processor while that user mode state is frozen in the registers...how could the user mode state be frozen on the processor while the kernel is running its own thread on the processor and saving that frozen state to the TCB?
Sorry if my question wasn't really clear before.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: concerning thread context switches

Post by Brendan »

Hi,
icealys wrote:yeah i was just wondering how the kernel actually saves the registers...meaning...how the registers stay frozen in a certain state and then the kernel somehow runs on the processor while that user mode state is frozen in the registers...how could the user mode state be frozen on the processor while the kernel is running its own thread on the processor and saving that frozen state to the TCB?
Sorry if my question wasn't really clear before.
The kernel doesn't run on the processor while that user mode state is frozen in the registers. The kernel saves the user mode state (e.g. on the stack), so that there's no user mode state in the registers while the kernel is using them.


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
icealys
Member
Member
Posts: 60
Joined: Mon Feb 17, 2014 3:54 pm

Re: concerning thread context switches

Post by icealys »

when you say the kernel saves the user mode state(e.g. on the stack)...where does the kernel first copy the state from in order to put it on the stack? which brings me back to the original question...I thought that the state is inside the processor, then the kernel comes in and copies the state(registers) to the stack. Is this the case?
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: concerning thread context switches

Post by Brendan »

Hi,
icealys wrote:when you say the kernel saves the user mode state(e.g. on the stack)...where does the kernel first copy the state from in order to put it on the stack? which brings me back to the original question...I thought that the state is inside the processor, then the kernel comes in and copies the state(registers) to the stack. Is this the case?
The user mode state is in CPU registers. It's extremely easy to for the kernel to push values in CPU's registers (the user mode state) onto the stack.

For an example, see any documentation that describes the PUSHAD instruction (which pushes all of the general purpose register's contents onto the stack).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
icealys
Member
Member
Posts: 60
Joined: Mon Feb 17, 2014 3:54 pm

Re: concerning thread context switches

Post by icealys »

Let me see if I understand this correctly. The user mode thread calls the kernel and the kernel copies the user mode stack into the kernel stack...this includes the stack pointer and the return address. Then the kernel copies the registers into the kernel mode stack. Is this correct? and if so would the return address be used to fill in the instruction pointer when it gets executed at a later time? I did some looking around on this site...http://stackoverflow.com/questions/1263 ... -internals ... and it sais that the instruction pointer and stack pointer are saved to the kernel mode stack. The only way I can think of the instruction pointer being saved is through the return address when it is saved on the call stack when the cpu is interrupted. I don't think the instruction pointer register would be saved by the kernel copying the register because the kernel would be an instruction itself using up the instruction pointer at that point.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: concerning thread context switches

Post by Brendan »

Hi,
icealys wrote:Let me see if I understand this correctly. The user mode thread calls the kernel and the kernel copies the user mode stack into the kernel stack...this includes the stack pointer and the return address. Then the kernel copies the registers into the kernel mode stack. Is this correct?
Typically; user mode code calls the kernel and the CPU switches to the kernel's stack and puts the "return CS and EIP" (and possibly EFLAGS and other things) on the kernel's stack. Then the kernel's code saves whatever registers (containing user mode state) it's planning to use on the kernel's stack too.

When the kernel wants to return back to user mode it does the reverse of this (popping the values it put on the stack back into registers, and letting the CPU load the "return CS and EIP" during the switch back to user mode).

There's normally no need to copy anything from user mode stack to kernel stack (e.g. kernel API parameters passed in registers).

Of course in theory there's at least 15 different variations of this (call gate, interrupt gate, task gate, sysenter, syscall; each with different possibilities for parameter passing); but the basic idea is mostly the same.


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: concerning thread context switches

Post by Combuster »

icealys wrote:The user mode thread calls the kernel and the kernel copies the user mode stack into the kernel stack.
No it doesn't. Why should it make a copy of something that is large and already has it's own bit of memory allocated?
this includes the stack pointer and the return address.
INT does that for you. You will have to look up how interrupts and exceptions work to see what they do to the stack.
Then the kernel copies the registers into the kernel mode stack.
This is the only thing the kernel has to do explicitly.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
icealys
Member
Member
Posts: 60
Joined: Mon Feb 17, 2014 3:54 pm

Re: concerning thread context switches

Post by icealys »

oh ok...so INT takes care of putting the instruction pointer and stack pointer on the kernel stack...thanks so much!
Post Reply