> > The woken thread will be dispatched no later than on the next timer > > interrupt (see above case 2). It might be run earlier (case 1 above), but > > then it can run for a complete timeslice (which is typically much longer > > than the timer period).
> Yeah, that's what i want. Thanks a lot. What's more, does time donation (you > said which is typically much longer than the timer period) happened here? if > so, could you explain it (time donation) a little more for me? Typical timeslices are 10ms (on x86), the timer interrupt fires every 1000us (microseconds), i.e., every 1ms or 10 times per timeslice. That's what I meant with timeslices being much longer that the timer period. Timeslice donation always occurs when we switch threads behind the scheduler's back, i.e., during IPC. The kernel scheduler maintains a timeslice_tcb, which is a pointer to the thread on whose timeslice we run (and on which we base our decisions as to whether the current timeslice is over or not), but this is updated only in schedule(), end_of_timeslice(), and preempt_thread(), none of which is called during IPC. There we just use switch_to() ... If the low prio thread B sends an IPC to the high prio thread A, A will be woken and immediately dispatched (bypassing the scheduler) and continue execution on B's timeslice until the timeslice expires (or A yields or blocks). At the end of B's timeslice, the scheduler will be invoked and probably select A to run. This time, however, also the timeslice_tcb is updated to point to A, so that A will run on its own timeslice. > > The L4 kernel is not preemptible (interrupts are disabled while inside the > > kernel) except during string IPC and possibly during the recursive unmap > > operation: Here we explicitly enable interrupts to reduce IRQ handler > > latency. All other code paths through the kernel are rather short, so that > > making the kernel preemptible would not pay. > I known that for IA32 when entering kernel space, it's must through the int > gate(or call gate) whether interrupt or system call. And the after through > the gate ,all interrupts will be disabled(set IF flag). But, I didn't find > where these interrupts be enabled again?. Enabled when the interrupted > thread(or any thread?) return back to user level? Yes, interrupts are either implicitly turned on when leaving the kernel via iret (return from interrupt) or explicitly via sti (set interrupt flag, thus *enabling* interrupts) just before leaving the kernel via sysexit/sysret on the IPC path. Regards, Raphael
