I understand new linux kernel allow kernel space threads to be pre-empted. Can someone briefly explain how pre-empting works when executing in kernel mode? So, when a system call is made, a software interrupt will switch the thread into kernel mode and it will run whats necessary. Now, lets say its time slice is up - and another user thread runs and it also wants to execute in kernel space. (Or it could be a h/w interrupt). How does the kernel maintain the integrity of any structures that it was modifying for T1 when it got interrupted?
4
votes
@shekhar Thats dosent really answer my question. Im not talking about process state - Im talking about being pre-empted while in kernel mode - lets say you were in the middle of updating some data struct in the kernel
– excalibur
What makes you "understand new linux kernel allow kernel space threads to be pre-empted"? Can you provide any reference to source of this assumption? Which commit github.com/torvalds/linux/commits/master introduced it?
– xmojmr
@xmojmr - "new" is probably not appropraite but anyway here's one article that desribes new features in 2.6 linuxjournal.com/article/7477 "As of kernel 2.6, the kernel is preemptible. A kernel task now can be preempted, so that some important user application can continue to run...Thus, under Linux 2.6, the kernel now can be interrupted mid-task, so other applications can continue to run"
– excalibur
2 Answers
6
votes
The Linux kernel protects its data structures the same way as anything that runs in a multithreaded environment.
It will likely use some sort of lock to protect data structures that must be accessed atomically. Usually, these include spinlocks, mutexes and semaphores.
There are also functions that disable preemption but this isn't normally used explicitly since locking code will take care of this implicitly.
3
votes
Can someone briefly explain how pre-empting works when executing in kernel mode?
It works just like any other context switch. When an interrupt happens in pre-emptible code the CPU jumps to the corresponding interrupt handler and leaves some info on the stack (typically the RIP/CS/EFLAGS/RSP/SS registers of the interrupted task) to be able to return to the pre-empted task later.
So, when a system call is made, a software interrupt will switch the thread into kernel mode and it will run whats necessary. Now, lets say its time slice is up - and another user thread runs and it also wants to execute in kernel space. (Or it could be a h/w interrupt). How does the kernel maintain the integrity of any structures that it was modifying for T1 when it got interrupted?
Let's call the first (the pre-empted) task T1 and the new task T2. If T1 was accessing some data structures, then T1 had to acquire the locks first. All of the kernel's data structures that could possibly be accessed by multiple threads concurrently are protected by locks (almost). If T2 tried to access the same data structure, then it will fail to acquire the lock since T1 still has it, as a result T2 will block and give the CPU back to another task. After some time T1 will start executing again, release its locks, sleep again, switch back to T2, T2 acquires the lock, does its thing, releases the lock, etc.
If multiple threads try to access the same protected data concurrently, only the first thread will get access typically, all the other threads will have to wait.
