On Apr 29, 2009, at 6:08 AM, [email protected] wrote:
> You have the logic upside down.
What logic, where?
> Your code leads to major thrashing of tasks.
Um, how... I only witch out tasks at task completion and at TSI
> Unless you check the global state, you run the risk of starting and
> stopping a series of tasks IN THE SAME SECOND. because they all
> checkpointed, and there is a perverse chain of what to run next.
> Inspecting the global state is a much better solution than trying to
> figure
> out exactly what to do on a particular event as there is the
> probability
> that several events will happen during the same second.
Well, I hate to break this to you, but the basic core of that pseudo
code that you just slammed is pretty well lifted from what is
currently coded.
Which could be why I see the nonsense going on in the systems I have.
I would also point out that the only reason I came up with this sub-
optimal design is that you keep insisting that doing resource
scheduling on a second by second basis is the way to go. Now, you
insist that it isn't. Which is ti?
Remember, I am the guy that says that we should be slowing down the
speed of the scheduling so that we don't try to do everything at the
same second. A solution you keep rejecting because you want to run
resource scheduling every second.
Also, If you also read the code more carefully, the loop through the
list of events means that each checkpoint event is handled in order
one by one. You know, the code:
schedule-resources (event list)
iterate through event list
> No, the end of the loop is NOT the place to do the limit on how
> frequently
> anything can happen. The interprocess communications also occurs in
> this
> polling loop, and that has to happen much more frequently.
Again, that was what I understood from your assertions over time as to
how the system is constructed NOW ... with only minor adjustments to
adapt to the changes I suggest.
So, Sir John, you are real good at coming up with ways to prove that
no idea will work.
What we have doesn't work ...
Why don't you propose something that will work?
And, by the way, from your comments I am not convinced you actually
read the code ...
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
