AW: What happens on timeslice overrun?
wittmaennle at gmx.de
Mon Aug 15 15:17:20 CEST 2005
> RW> I have 2 questions on the RT part in DROPS:
> RW> 1.) I have 2 RT working threads, each with 3 timeslices:
> RW> Thread 1: period=10ms
> RW> ts1=30ms prio1=50
> RW> ts2=10ms prio2=30
> RW> ts3=20ms prio3=50
> RW> Thread 2: period=10ms
> RW> ts1=20ms prio1=40
> RW> ts2=5ms prio2=30
> RW> ts3=10ms prio3=40
> RW> Assume both threads are ready at the same time.
> RW> So thread 1 starts and does its work until it releases the
> RW> voluntarily or it's preempted by its preempter-thread. So say it
> RW> releases voluntarily after 20ms.
> When you say "it's preempted by its preempter thread", do you
> mean the situation when a preempter with a higher priority
> than the current thread receives a preemption IPC from the
> kernel and thus preempts the current thread?
That's what I meant. The preempter has a higher priority and receives
the IPC and thus "tells" (via IPC or via common variable if in same
address space) the thread to stop the work.
> RW> Who will get the left 10ms? I guess nobody.
> When a thread is preempted (that means it gets involuntarily
> descheduled), the remaining time quantum is saved and later
> restored when the thread is scheduled again. If the thread
> yields its scheduling context (that means it voluntarily
> gives it away), the time quantum is no longer available to
> the thread. A yield can happen in two ways depending on the
> target thread id specified:
> 1) if the target ID is the NIL_ID, then the thread yields its active
> scheduling context to noone - the time is effectively gone. This is
> what next_reservation does. Note that the kernel checks
> the user-specified
> ID, to guard against the case where a thread wants to
> yield its active
> scheduling context and the time quantum on that scheduling
> context expires
> 2) if the target ID is a valid thread ID in the system, then
> the action
> depends on whether the specified thread is ready to run:
> a) if it is, then the current thread donates the current scheduling
> context to the specified thread and that thread then becomes the
> current thread. This is similar to what happens during
> a donating IPC.
> b) if the specified thread is not ready, then the current
> context is gone, similar to 1)
How can I specify the target ID? When creating the thread? But how?
> RW> Or can I assign my left time to a specific thread, say
> ts2 of thread
> RW> 1, that is has 20ms after recognizing that ts1 was finished 10ms
> RW> earlier?I could do with l4_rt_change_timeslice(), but this would
> RW> probably not work for the the current period! (or yes?)
> A thread can yield the current scheduling context to another
> thread as described in 2a) above. Note that the thread will
> yield the current scheduling context (which may not
> necessarily be the thread's own active scheduling context).
> As an example consider:
> A sends a donating IPC to B, now B runs on A's scheduling
> context. If B yields to C, then C will run on A's time and B
> will not donate its own scheduling context. If the current
> scheduling context is in fact the active scheduling context
> of the donating thread, then realize that the donating thread
> will likely encounter a timeslice overrun soon after the
> yield (the donatee will consume the time quantum until it runs out).
> If you'd rather avoid that, then the donatee will have to
> yield the scheduling context back to the owner (the original
> donator) who then has to yield it to noone.
> Changes to the time quantum of a scheduling context are only
> visible the next time that scheduling context becomes the
> current scheduling context. That means if you change the
> current scheduling context, then the change will not be
> visible immediately.
OK, that's clear now.
> RW> 2.) Consider we have a deadline miss. And we say
> RW> l4_rt_next_period(): would it wait for the beginning of the next
> RW> (which means:
> RW> period 1: deadline miss
> RW> period 2: call next period (because we think we're
> RW> still in period 1)+ wait to end of period
> RW> period 3: normal work)
> RW> Or do I have to care that we do not call
> RW> l4_rt_next_period() in case of a deadline miss?
> If your thread misses its deadline right before it wanted to
> call l4_rt_next_period, then l4_rt_next_period blocks the
> thread until the end of the new period started due to the
> deadline miss. Since this is likely not what the thread
> intended to do, it's the preempter's job to handle that
> situation, e.g. by ex_regs'ing the thread out of it's
> l4_rt_next_period call.
More information about the l4-hackers