In my kernel configuration CONFIG_PREEMPT is not set. Since schedule() is not allowed in interrupt handler how does round robin type of scheduling is implemented in linux kernel. i.e. Who calls the scheduler so often. In entry_32.S it calls preempt_schedule_irq only if CONFIG_PREEMPT is set.
What happens is the timer on the CPU is set to interrupt the kernel every so often. But we can't just call schedule from interrupt context right? So what the kernel does is a neat trick. It changes the currently executing task while executing the handler and then returns. What this effectively does is switch out the context from underneath the handler so the handler completes but at the same time the next context to run is now the next task that will execute. Read up on do_context_switch (IIRC I think that's what it's called) and you will see that it switches it's stack and context from underneath the current execution and resumes the same function in another context.
And CONFIG_PREEMPT only applies to kernel code preemption in kernel context. Userspace tasks will always preempt. All this means is that any kernel code that starts to execute runs to completion (unless you call schedule() yourself or block waiting for I/O, etc....). Normally the kernel can preempt as long as it does not hold any locks except in certain cases where acquiring a lock can put the thread to sleep.
Related
Is the thread in MS Windows with C++ a time slice or the execution of a function or both?
A thread is executing a function which is a block of code inside an outer loop. If you send a signal (via a global variable) to break from the outer loop. The function returns, but what happens to the running thread assuming it is a time slice of execution?
Neither.
If your scheduler is set to a time-slice algorithm then the time-slice represents when and how long your thread will run.
A thread is an object that manages a block of executable code that can be scheduled. Typically, as part of thread creation you pass a function pointer to that block of code. When the "job" of the executable code is done the thread is destroyed.
In 32-bit and 64-bit Windows, every thread runs a specified function. Conceptually speaking, the initial thread of a new process runs the application's main function, and every additional thread runs a function specified by the programmer when the thread is created. See the documentation for CreateThread; the lpStartAddress argument specifies the function for the thread to run.
(In fact, each thread also runs operating system code, and usually runtime library code as well, but that's an implementation detail that doesn't matter for our purposes.)
Conceptually, when any particular thread is running on a particular CPU core, it might stop for either of two reasons: because the thread has stopped running altogether, or because of a context switch. In the case of a context switch, the thread will be started up again at a later time, and from the thread's point of view everything will look the same as it did when it was interrupted.
(In fact, the OS may also interrupt the thread in order to run device driver or other operating system code. This doesn't involve a context switch; the device driver code runs in the context of the interrupted thread, which is one of the reasons device drivers are hard to write.)
Here are some of the reasons the thread might stop running altogether ["exit"]:
The function the thread was created to run has exited.
The thread calls ExitThread().
Some other thread calls TerminateThread().
Here are some of the reasons there might be a context switch:
The thread's timeslice has expired.
Another thread with a higher priority has become ready to run.
The thread calls Sleep() or one of the wait functions.
It's hard to tell what you're trying to ask, so this may not have addressed it. But perhaps it will clarify things enough to allow you to ask your question in words I can understand.
What happens if a running tasklet is interrupted by a hardware interrupt. I mean if there is a tasklet in the middle of execution and a hardware interrupt happens. Does the tasklet complete its execution before the interrupt code is run, or the tasklet is executed after the interrupt.
Ordinarily a hardware interrupt will be executed immediately. On return, the tasklet will resume execution.
It is possible and even common that a tasklet will disable interrupts during short critical sections while it manipulates shared data structures.
Taskelts can be interrupted by hardware interrupts. See, e.g this.
I know that the kernel scheduler is run periodically. This period is determined by a timer.
However, I have been unable to find where the IRQ for the timer interrupt is and the entire flow from beginning to end of the scheduler code.
I understand that the schedule() function may potentially have several entry and exit points..
but could someone point me towards where to look for these?
From the kernel source, I've gathered that __schedule() is the main schedule function that seems to be called from schedule()..
but what calls schedule()..and what calls the function that calls schedule.. ..
There are actually two schedulers, or rather two scheduling codes in the Linux kernel. There is a core scheduler, which you yourself mentioned called schedule() which calls __schedule(). schedule() is called from many points in the kernel:
Explicit blocking, like in case of semaphores, mutexes etc.
A flag TIF_NEED_RESCHED is checked on interrupts and on return to userspace, if set then schedule is called.
A process wakes up.
There is another scheduler code with the name scheduler_tick()[this too resides in core.c], which is a periodic scheduler and is called by the timer code(timer.c) via interrupt with a frequency of HZ, i.e. scheduler_tick() is called HZ times in one second. HZ is hardware dependent and its value varies between 100-1024. scheduler_tick() calls the task_tick() of the scheduling class to which the current task on the processor belongs.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686289%28v=vs.85%29.aspx
According to msdn, in the remarks sections, it states:
"If the thread that set the timer terminates and there is an associated completion routine, the timer is canceled. However, the state of the timer remains unchanged. If there is no completion routine, then terminating the thread has no effect on the timer."
Then further down, it states:
"If the thread that called SetWaitableTimer exits, the timer is canceled. This stops the timer before it can be set to the signaled state and cancels outstanding APCs; it does not change the signaled state of the timer."
Hence my question,
if I have one thread calling SetWaitableTimer without an associated completion routine and another thread calling WaitOnMultipleObjects(passing in the timer object handle) and the thread that calls SetWaitiableTmer exits shortly thereafter, would the timer object be cancelled or would it still become signaled when the period expires?
To give more information directly from the implementation of waitable timers: if you use a CompletionRoutine, the timer is placed on a linked list chained off the thread which called SetWaitableTimer. When the thread is terminated, the kernel walks the dying thread's linked list and cancels are timers which are still queued.
If you're not using a completion routine, the timer is never added to any thread's linked list and thus isn't cancelled when any particular thread dies.
The documentation is somewhat unclear. I think the best you can do is test it yourself. I believe however that the timer cancels automatically only if the I/O completion routine is used.
I can give some "theoretical" background about windows APCs, to justify my (educated) guess.
APC = "asynchronous procedure call". In windows every user-mode thread is equipped with a so-called APC queue, a system-managed queue of procedures that must be called on this thread. A thread may enter a so-called "alertable wait" state (on purpose), during which it may execute one or more of the procedures in this queue. You may either put the procedure call in the APC queue manually, or issue an I/O, which on completion will "put" the procedure call there.
In simple words the scenario is the following: you issue several I/Os, and then you wait for either of them to complete (or fail), and, perhaps, some other events. You then call one of the alertable-waiting functions: SleepEx, WaitForMultipleObjectsEx or similar.
Important note: this mechanism is designed to support a single-threaded concurrency. That is, the same thread issues several I/Os, waits for something to happen, and responds appropriately. All the APC routines are guaranteed to be called in the same thread. Hence - if this thread exits - there's no way to call them. Hence - all the outstanding I/Os are also cancelled.
There are several Windows API functions that deal with asynchronous I/O, whereas they allow a choice of several completion mechanisms (such as ReadFileEx): APC, setting an event, or putting a completion in the I/O completion port. If those functions are used with APC - they automatically cancel the I/O if the issuing thread exits.
Hence, I guess that waitable timer auto-cancels only if used with APC.
Can anyone please let me know the usage of schedule() function in linux kernel.
Who will schedule this scheduler thread.?
Thanks in advance
Two mechanism are available: voluntary or hardware-based.
http://lwn.net/Articles/95334/
Arising from a recent patch, voluntary preemption has been introduced into the kernel:
http://kerneltrap.org/node/3440
This means the CPU will explicitly surrender the current job and let the scheduler take over to select the next tasks on the active tasks list. It has been found that this way of voluntary preemption improved performance over involuntary preemption (which is timer clock-based)
More info:
http://wiki.osdev.org/Context_Switching (software vs hardware context switching - similar to what we are talking here)
http://wiki.osdev.org/Scheduling_Algorithms
There is no scheduler thread in the Linux kernel. There are specific situations in which the schedule() function is called. For example:
1) When a process or kernel thread explicitly calls it in kernel mode. A process generally calls schedule() function if it needs to wait for some event to occur; like availability of data from an input-output device.
2) When a process of priority higher than the current process was waiting for some event and the event occurs.
3) When the time slice allocated to the current process expires.