Re: [Gems-users] A question on event scheduling

["Niket Agarwal (niketa@xxxxxxxxxxxxx)" <niketa@xxxxxxxxxxxxx>]

Hi Lide, 
If you look at MessageBuffer::isReady(), it checks whether a MessageBuffer is ready by checking whether the top message in the buffer is scheduled for dequeue at a time <= current time. Since, a message buffer is a priority heap of messages sorted by time, if the top message is not ready, no other message can be ready. Because the "time" for other messages will be >= the time of the top message. 

In the example you have provided, when the message is enqueued into the input buffer of the next Throttle, it will be enqueued behind messages that have a "time" <= this message. So, it will not block any message. 

This is what I think happens.

- Niket 

> Is it possible that the current peeked msg is not ready but there are some other ready msgs in this buffer? If so, the current msg will block the ready msgs because the while loop in the wakeup function of PerfectSwitch or Throttle will terminate when it encounters a *unready* msg, no matter the following msgs are ready or not.
>
> This is not something like HOL blocking since all the msgs might be still conceptually in transit, e.g. in the throttle situation, one msg is enqueued into an output buffer (which is also an input buffer of the next Throttle) as soon as it comes out of the current input buffer, but its ready time in the next throttle is set to reflect the link latency. In other words, this msg will ocupy a position in the input buffer of the next Throttle although it's actually still in transit on the link, but it might block some other ready msgs in the same buffer during this time slot.
>
> Does what I am thinking possibly happen?
>
> Lide
>
> On 8/28/07, Mike Marty <mikem@xxxxxxxxxxx> wrote: Even if the consumer is woken up, all the logic that actually removes a
> message from a MessageBuffer should be inside a check of
> MessageBuffer::isReady().  Take a look at this function...if I recall,
> there should be a check to ensure that the head message (determine by
> earliest arrival time) is equal to the current time.
>
> --Mike
>
> Niket Agarwal (niketa@xxxxxxxxxxxxx) wrote:
> > >From what I understand, the EventQueue in Gems does not enforce any ordering of Consumers scheduled to wakeup at a particular time. Now suppose, I enqueue a message in a buffer which is otherwise free, at cycle 'x' and schedule the wakeup of its consumer the next cycle 'x+1'. But, the consumer is woken up by some other event during this cycle 'x' and checks this message buffer also and picks up the message during cycle 'x'. Since when a consumer wakes up, it does not know who has woken it up, this situation can certainly occur. Note that this is something that was supposed to be done in cycle 'x+1'.
> >
> > This can happen for example in PerfectSwitch. Am I missing a trick here ? How does ruby avoid such a scenario ?
> >
> > Thanks,
> > Niket
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> >
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.