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

[Hang Su]

Thanks. Let me review the source code again by taking your explanation.

On Tue, Mar 6, 2012 at 5:34 PM, Andrea Bastoni <bastoni at cs.unc.edu> wrote:

> 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
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20120307/2418c3d4/attachment.html>