On Wed, 3 Jun 2009 02:25:15 +0800 Sean (S) wrote:
S> I got confused in several points S> S> Currently, I don't trace how to implement timeout in Fiasco. I assume when S> it expired, the timeout handler will execute.
There exists a timeout base class and 3 derived classes for specific timeouts, namely IPC timeouts, timeslice timeouts and deadline timeouts. When a timeout expires, the virtual method ::expired is called; all derived classes overwrite this method such that code specific to the timeout type is executed.
S> 1. If timeout handler is executed inside Fiasco S> => Fiasco needs to determine which group of threads needs to change S> state and the information about time interval. So I need to port all S> control rules of control server into Fiasco? S> => Or I need to maintain a list in Fiasco and update this list from the S> control server on top of Fiasco. But how to do it?
Have a look at how the current real-time scheduling framework controls deadlines, period etc. from user space. You would have to design a similar interface that downloads interval start/end times and affected threads into the kernel.
S> 2. If timeout handler is executed as a user thread on top of Fiasco. How S> the control server on top of Fiasco changes the other user thread's state? S> => I need to provide the system call interface or other issues to S> change the user thread's state. S> => Can I implement it by fixing the existent system call thread_ex_regs S> or I need to add a new system call?
The simplest thing here is to add a new system call that allows setting and clearing the Thread_ineligible flag of threads from user mode. I do not recommend overloading the ex_regs system call because that only complicates things.
S> If I use the system call thread_ex_regs, I think it will have the problem: S> If there are a lot of threads needed to change the state, I need to S> call the system call many times for every thread. it seems to be a huge S> overhead here.
Correct. But you can design your system call such that you change the state of multiple (all?) affected threads at once. However, note that the more threads change state on interval boundaries, the more latency you will add in the kernel even if you can do it with just a single system call invocation.
If this is a problem, you could take an alternate approach to the whole problem: You could maintain a run queue for each time interval and when one interval ends and another starts, you could just switch run queues. While this removes the need to track eligible/ineligible state of threads, you now have to decide into which run queue a particular threads should go when it is ready. This approach requires less thread state changes, but requires much more memory.
Cheers,
- Udo