On Apr 30, 2009, at 10:12 AM, [email protected] wrote: > Not until the next state is acted on - which happens after the state > is > fully determined. Is there a bug someplace, yes, but merely setting > the > flag does NOT actually change the state until the flag is acted upon.
I cannot follow the spaghetti code logic that follows. But, you are making a nonsense argument. The code starts with the assumption that all tasks are preempted. If that is done, then any flaw in the logic that follows means that all tasks are preempted. Since I can watch blocks of tasks being preempted, ergo, not hard for me to see the reason why. Also, you cannot assert that TSI is respected when the initial reaction of the procedure it to start with all tasks preempted. And, even though I have seen this behavior, I have never in any of the logs seen the message where the preemption code is marking a task for preemtion. Never... not once ... You know, this message: "[cpu_sched_debug] preempting %s" I just loaded the files again, and tried again not once ... 48 M of log files with the logging on in quite a few of them and not once instance of that flag being printed. That tells me that the code that is SUPPOSED to be selecting tasks that are preemptable is not working, never has. But because we flag all tasks to start as preempted, well, we don't respect TSI and the system shows massive instability. _______________________________________________ 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.
