Hi Eddie, On 5/21/07, Eddie Kohler <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > 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 > > [email protected] > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
