[Click] strange LinkUnqueue behaviour

[Peter De Cleyn]

Hi Eddie,

On 5/21/07, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> Peter,
>
> Thanks a million for this test case.  It finally let me find what I think was
> the problem.
>

Your weclome, I'm glad it helped you solve this scheduling issue.

> Here is an expanded checkin message to explain the fix.
>
> fix notifier problem, perhaps finally at last.  Here is what was happening.
> fast_reschedule() does _pass += _stride.  fast_schedule() looks at the first
> _pass scheduled on the router, OR USES 0 IF THERE IS NO TASK ON THE ROUTER AT
> THE MOMENT.  Result: if a task is schedule()d while the router is empty,
> before a fast_reschedule(), the newly schedule()d task will have a really tiny
> _pass (like based on 0), and the new task will have a much larger _pass -- so
> large as to be negative.  Then the new task will win for a long time, even
> though the schedule()d task is actually sitting around scheduled.  Better
> plan: keep track of the current _pass in RouterThread.  Thanks to Peter De
> Cleyn for an example.
>
> Anonymous CVS is updated.  Does it work for you?

It certainly solved this testcase. I'll try to stress test it tomorrow ;-)


Peter

---------------------
Peter De Cleyn

Universiteit Antwerpen
Departement Wiskunde-Informatica
Middelheimlaan 1
2020 Antwerpen

peter.decleyn at ua.ac.be

> Eddie
>
>
>
> Peter De Cleyn wrote:
> > Forgot to add in my previous mail, that the problem does not occur
> > when using a SimpleQueue. I therefor think that the reason for this
> > behaviour should be found within the notifier mechanism. I likewise
> > discussion was already covered in previous posts and updates, but it
> > seems the updates made then did not solve it all.
> >
> > Peter De Cleyn
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>