Thanks. Let me review the source code again by taking your explanation.<br><br><div class="gmail_quote">On Tue, Mar 6, 2012 at 5:34 PM, Andrea Bastoni <span dir="ltr"><<a href="mailto:bastoni@cs.unc.edu">bastoni@cs.unc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 03/06/2012 10:42 PM, Hang Su wrote:<br>
> Hi all:<br>
><br>
> I have a couple of questions as described as followings:<br>
><br>
> 1. struct bheap is binary heap and struct bheap_node represents each heap node<br>
> in a heap, right ? A traditionally binary heap node could have up to two<br>
> children, left one and right one. In struct bheap_node, I see its has next and<br>
> child. Which is the corresponding left child and right child ? Or, child and<br>
> sibling representation is used, so that a bheap_node only maintain its left<br>
> child and its sibling. And degree represents how many children it has or what ?<br>
>  In struct bheap, there are head and min. If it was a minimum heap, head and min<br>
> should points to the same bheap_node, which is the heap root, after each bheap<br>
> operation like insertion and deletion. When does they differs ?<br>
><br>
> 2. In rt_domian.h, there is a struct rt_domain_t. What is the difference between<br>
> release_queue and tobe_released. From the comments, they are all related to<br>
> release queue. But i am a little bit confused about them. Inside requeue<br>
> function in sched_gsn_edf.c, a task is linked in tobe_released instead of<br>
> release_queue through calling add_release(&gsnedf,task), if it has not been<br>
> released . If an example could be shown, it is pretty much clear for me. For<br>
> example, we have a task set with two tasks, T1(c1,p1) = (3,5)  and<br>
> T2(c2,p2)=(2,6). This task set will be scheduled on one processor by EDF. At<br>
> time 0, both of their jobs are released. And the release_queue.slot[5] ,<br>
>  release_queue.slot[10], ..., release_queue.slot[ min( 5*i, RELEASE_QUEUE_SLOTS)<br>
> ], maintain jobs from T1, which will be released within window-sized<br>
> RELEASE_QUEUE_SLOTS.  is that right ?<br>
<br>
</div></div>Hi Hang,<br>
<br>
Not sure I get it right what you mean with "window-sized" release_queue_slots,<br>
since time2slot() will pick the slot (mod release_queue_slots) depending on the<br>
release_time.<br>
<br>
Anyway, tobe_released is there (but beware, I'm a bit rusty with that code) just<br>
as a "buffer" before the real insertion into the release_queue. In<br>
arm_release_timer() we might need to release the release_lock if we need to<br>
reinitialize the task heap. If release_lock would have been the only lock<br>
protecting the task(s) to be inserted into the release queue, we wouldn't have<br>
protected enough the to be released tasks. Therefore we use a buffer (with<br>
another lock) to decouple the move into the release queue.<br>
<br>
I hope it helps,<br>
- Andrea<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</div></div></blockquote></div><br>