How does a kernel return from the thread

1
votes

I am doing some study hardcore study on computers etc. so I can get started on my own mini Hello World OS.

I was looking a how kernels work and I was wondering how the kernel makes the current thread return to the kernel (so it can switch to another) even though the kernel isn't running and the thread has no instruction to do so.

Does it use some kind of CPU interrupt that goes back to the kernel after a few nanoseconds?

2
multithreadingprocessoperating-systemkernelbootloader
wiki.osdev.org/Multitasking_Systems – Mat
Frankly, I don't think anyone would have guessed you didn't have any programming experience until you mentioned "without programming experience"—the fact that you mentioned it just makes you sound insecure! – Asherah
I just said that because on tonnes of other sites I have went to always mentioned stuff like "you need programming experience". But thanks for the feedback, I am new to this site and didn't really think that people would assume I knew programming... – hddh
Without necessary prior reading and research, such questions usually create more questions and it becomes a boring and tiresome process for both parties and becomes much less effective than reading. For that, it's a good idea to clarify concepts with a little research. Here is a nice article about that: mattgemmell.com/2008/12/08/what-have-you-tried – Sedat Kapanoglu

2 Answers

0
votes

Does it use some kind of CPU interrupt that goes back to the kernel after a few nanoseconds?

It is during timer interrupts and (blocking) system calls that the kernel decides whether to keep executing the currently active thread(s) or switch to another thread. The timer interupt handler updates resource usages, such as consumed system and user time, for the currently running process and scheduler_tick() function that decides whether a process/tread need to be pre-empted.

See "Preemption and Context Switching" on page 62 of Linux Kernel Development book.

The kernel, however, must know when to call schedule(). If it called schedule() only when code explicitly did so, user-space programs could run indefinitely. Instead, the kernel provides the need_resched flag to signify whether a reschedule should be performed (see Table 4.1).This flag is set by scheduler_tick() when a process should be preempted, and by try_to_wake_up() when a process that has a higher priority than the currently run- ning process is awakened.The kernel checks the flag, sees that it is set, and calls schedule() to switch to a new process.The flag is a message to the kernel that the scheduler should be invoked as soon as possible because another process deserves to run.

0
votes

Does it use some kind of CPU interrupt

Yes! Modern preemptive kernels are absolutely dependent upon interrupts from hardware to deliver good I/O performance. Keyboard, mouse, disk, NIC, USB, etc. drivers are all entered from interrupts and can make threads that are waiting on them ready/running when required (e.g., when data is available).

Threads can also change state as a result of making an OS call that changes the caller's own state of that of another thread.

The interrupt from the hardware timer is one of many interrupt sources and is only special in that many system operations have timeouts that are signaled by this interrupt. Other than that, the timer interrupt just causes a reschedule which, in most cases, changes nothing re. the ready/running state of threads. If the machine is grossly CPU-overloaded to the point where there are more ready threads than there are cores, there is a side-effect of the timer interrupt that causes CPU time to be shared amongst the ready threads.

Do not fixate on the timer interrupt—the other driver interrupts are absolutely essential. It is not impossible to build a functional preemptive multithreaded kernel with no timer interrupt at all.