AW: What happens on timeslice overrun?

[Rene Wittmann]

> RW> I have 2 questions on the RT part in DROPS:
> RW> 
> 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> 
> RW> Thread 2: period=10ms
> RW>           ts1=20ms prio1=40
> RW>           ts2=5ms  prio2=30
> RW>           ts3=10ms prio3=40
> RW> 
> 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
>    simultaneously.
> 
> 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 
> scheduling
>       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.
> 

OK, clear.

Thanks,
Rene