Hi Adam,
thank you, that makes things clearer to me, especially the information of the timer for managing preemption.
In a previous mail, you stated that a thread has a Sched_context object embedded that stores scheduling-related information. However, I cannot find a 1:1 relation from a Thread to a Sched_context object. I've found various calls of the sched_context() method in 'thread.cpp', which is defined in 'context.cpp'. Furthermore, there are several calls of the current() method in 'thread.cpp' (returning the current context), which is defined in 'context_base.cpp'.
So my main question is: What is the exact relation of a Thread object to all these classes?
I assume that a Context object is cpu-specific, i.e. each Context object points to its home cpu. Is that right? This would make sense since there is a home_cpu attribute and a schedule() method in that class that handles the scheduling on a certain cpu.
But what's the matter with Sched_context? It seems to me that there is no 1:1 relation from a Thread to a Sched_context since the sched_context() method called in 'thread.cpp' is defined in 'context.cpp'. So is a Sched_context cpu-specific, too? This would not make sense to me as a Sched_context object stores thread-specific information such as the priority and the remaining quantum of a thread.
Thanks in advance!
Best regards, Valentin
On 07/02/2014 12:30 AM, Adam Lackorzynski wrote:
On Mon Jun 30, 2014 at 12:08:00 +0200, Valentin Hauner wrote:
I've added a new config directive for 'sched_edf' to the Modules.* files in 'kernel/fiasco/src', that is: PREPROCESS_PARTS-$(CONFIG_SCHED_EDF) += sched_edf This enables the user to compile the kernel with EDF scheduling when setting this directive, right?
This adds the preprocess tag 'sched_edf' which are used in the expressions for the INTERFACE and IMPLEMENTATION blocks. With that you can chose whether a block of code is included in compilation or not.
I want to implement the preemptive EDF algorithm, i.e. any running task must be preempted if a new task with a shorter deadline arrives. dominates() from sched_context-edf.cpp and next_to_run() from ready_queue_edf.cpp are designed to choose the one with the shortest deadline, but how can I tell Fiasco to act preemptive?
So, on one CPU only one thread can be running at a time. Others might be ready to execute but not running. Regarding preemption, the timer interrupt drives scheduling (see Thread::handle_timer_interrupt) which calls schedule() whenever there's something to do, i.e. a timeout has expired. Of course schedule() might also be called for other reasons, for example when threads change their ready state. In the scheduler implementation you'll see whenever some new thread arrives or one leaves, so I think the preemption as you need it is already there.
Adam