Fixed a bug in locality scheduling. When old work was being sent,

the daily_result_quota constraint was not being enforced.
Normally this constraint is enforced in the work_needed()
function.  However note that the critical send_work() function
NEVER checks work_needed() [DAVID, perhaps it should?] before
calling send_work_locality() or scan_work_array().  Then, when
send_work_locality() was called, it would in turn call
send_old_work() immediately, WITHOUT checking to see if
work_needed() was TRUE.  This allowed the daily_result_quota
constraint to be broken.

    Possible fixes included:
      test work_needed() before calling send_old_work()
      test work_needed() WITHIN send_old_work()
      test work_needed() within possibly_send_result()
      test work_needed() within wu_is_infeasible()

Conclusion: work is ONLY sent by the function
possibly_send_result() which is called in two places in
sched_locality.C: once in send_results_for_file() and once in
send_old_work().  The first of these DOES check the value of
work_needed().  The second does NOT.  So I added a check of
work_needed() within send_old_work().  A also added
added another check of work_needed() at the top of
send_results_for_file() BEFORE any DB access is done.  It might be
better to put this test of work_needed() lower down (within
possibly_send_result()) or higher up (where send_old_work())
is called.  I am not sure. David, I'd appreciate your advice.

svn path=/trunk/boinc/; revision=5482
This commit is contained in:
Bruce Allen 2005-02-20 14:19:12 +00:00
parent ca9f0ea0c8
commit 73a99d6d17
2 changed files with 43 additions and 0 deletions

View File

@ -25056,3 +25056,37 @@ Janus 20 Feb 2005
html/inc/
image.inc
Bruce 20 Feb 2005
Fixed a bug in locality scheduling. When old work was being sent,
the daily_result_quota constraint was not being enforced.
Normally this constraint is enforced in the work_needed()
function. However note that the critical send_work() function
NEVER checks work_needed() [DAVID, perhaps it should?] before
calling send_work_locality() or scan_work_array(). Then, when
send_work_locality() was called, it would in turn call
send_old_work() immediately, WITHOUT checking to see if
work_needed() was TRUE. This allowed the daily_result_quota
constraint to be broken.
Possible fixes included:
test work_needed() before calling send_old_work()
test work_needed() WITHIN send_old_work()
test work_needed() within possibly_send_result()
test work_needed() within wu_is_infeasible()
Conclusion: work is ONLY sent by the function
possibly_send_result() which is called in two places in
sched_locality.C: once in send_results_for_file() and once in
send_old_work(). The first of these DOES check the value of
work_needed(). The second does NOT. So I added a check of
work_needed() within send_old_work(). A also added
added another check of work_needed() at the top of
send_results_for_file() BEFORE any DB access is done. It might be
better to put this test of work_needed() lower down (within
possibly_send_result()) or higher up (where send_old_work())
is called. I am not sure. David, I'd appreciate your advice.
sched/
sched_locality.C

View File

@ -391,6 +391,10 @@ static int send_results_for_file(
char buf[256], query[1024];
int i, maxid, retval_max, retval_lookup;
if (!reply.work_needed(true)) {
return 0;
}
// find largest ID of results already sent to this user for this
// file, if any. Any result that is sent will have userid field
// set, so unsent results can not be returned by this query.
@ -752,6 +756,11 @@ static int send_old_work(
DB_RESULT result;
int now=time(0);
if (!reply.work_needed(true)) {
return 0;
}
boinc_db.start_transaction();
if (t_min != INT_MIN) {