[LITMUS^RT] Questions on data struct bheap and rt_domain_t

[Andrea Bastoni]

On 03/06/2012 10:42 PM, Hang Su wrote:
> Hi all:
> 
> I have a couple of questions as described as followings:
> 
> 1. struct bheap is binary heap and struct bheap_node represents each heap node
> in a heap, right ? A traditionally binary heap node could have up to two
> children, left one and right one. In struct bheap_node, I see its has next and
> child. Which is the corresponding left child and right child ? Or, child and
> sibling representation is used, so that a bheap_node only maintain its left
> child and its sibling. And degree represents how many children it has or what ?
>  In struct bheap, there are head and min. If it was a minimum heap, head and min
> should points to the same bheap_node, which is the heap root, after each bheap
> operation like insertion and deletion. When does they differs ?
> 
> 2. In rt_domian.h, there is a struct rt_domain_t. What is the difference between
> release_queue and tobe_released. From the comments, they are all related to
> release queue. But i am a little bit confused about them. Inside requeue
> function in sched_gsn_edf.c, a task is linked in tobe_released instead of
> release_queue through calling add_release(&gsnedf,task), if it has not been
> released . If an example could be shown, it is pretty much clear for me. For
> example, we have a task set with two tasks, T1(c1,p1) = (3,5)  and
> T2(c2,p2)=(2,6). This task set will be scheduled on one processor by EDF. At
> time 0, both of their jobs are released. And the release_queue.slot[5] ,
>  release_queue.slot[10], ..., release_queue.slot[ min( 5*i, RELEASE_QUEUE_SLOTS)
> ], maintain jobs from T1, which will be released within window-sized
> RELEASE_QUEUE_SLOTS.  is that right ? 

Hi Hang,

Not sure I get it right what you mean with "window-sized" release_queue_slots,
since time2slot() will pick the slot (mod release_queue_slots) depending on the
release_time.

Anyway, tobe_released is there (but beware, I'm a bit rusty with that code) just
as a "buffer" before the real insertion into the release_queue. In
arm_release_timer() we might need to release the release_lock if we need to
reinitialize the task heap. If release_lock would have been the only lock
protecting the task(s) to be inserted into the release queue, we wouldn't have
protected enough the to be released tasks. Therefore we use a buffer (with
another lock) to decouple the move into the release queue.

I hope it helps,
- Andrea