I needed to limit BOINC work being done to reduce CPU overheating. I decided to force one particularly long running tasks to complete and then restart with a reduced workload.

So I did the following:
- Set the project to no new work
- Return to the Tasks window, highlight all tasks, and click Suspend.
- Intending to return and resume the one tasks I wanted to finish.

However, I think what happened is that BOINC suspended the first task in the window. BOINC then instantly started a new task. BOINC them came back and suspended the second task, which immediately started a replacement task. And so on.

I ended up with about half the waiting tasks going from "not started and holding no resources" to "started, holding resources, and suspended with 1 second running time".

I now know that I have to suspend all non-running tasks before suspending any running tasks to avoid this mess. But I think this is a bug in how suspend is handled.

Is there a way to report BOINC bugs, other than here?

Thanks,
++PLS

---

I am assuming you are just running one project on said computer?

Yes, at the moment just one project. I also should have said that I'm running BOINC 7.14.2.

++PLS

---

I have tried and am not able to replicate what you describe. I regularly highlight all tasks except for one or two which I wish to continue. Most often at the moment this is because I run tasks that require over 5GB of memory per task and if I run more than one at a time, there is an inordinate amount of swapping out to disk, slowing tasks by about 20% if I run two but running on all four cores tripling the time taken.

Edit: What platform are you on? I am running Ubuntu 19.04 and it may be only one one platform that there is a problem.

I am on Windows 10 v1809. And the key is to highlight EVERYTHING, including the running tasks. This has happened to be twice now. The project I'm running is SRBase. Perhaps part of the problem is that this project uses a fairly small program and can start a task quite quickly.

++PLS

---

This problem is already one of the identified issues in the backlog of improvements waiting for developer time.

Race condition when suspending tasks

My personal opinion (stated in that issue, but unverified) is that the 'race condition' in the title occurs because of the difference in speeds between:

a) the Manager sending each successive 'single task' RPC
b) the Client processing all parts of the suspend instruction

If a single running task is suspended, a message is sent to the project application to close and (potentially, depending on preference settings) remove itself from memory. The key question in your case might be how quickly SRBase apps can stop, rather than how quickly they can start.

Personally, if I need to do something like this, I use the same workround as you: suspend all unstarted tasks as a separate block action: only suspend the running task when there's nothing available to take its place.

If the project is fast to re-supply, try setting Activity to Suspend network activity first. That ought to stop that.

Or set 'No new tasks' for any project which might be in danger of over-fetching.

The project whose tasks are being suspended won't be at risk of fetching - work requests are inhibited for any project which has even one task suspended. The problem with 'Suspend network activity' is that it also prevents result files being uploaded and completed tasks being reported.

I've had to force a task or two to complete over all others a few times, but I don't think I have ever encountered this problem. I think what I did was I would suspend Boinc altogether, and then suspend the individual tasks that I didn't want to run (leaving the one or two that I do want to run alone). Then, I would resume the project itself. Does that help?

Suspending BOINC activity, then suspending individual tasks is also a good work around.

I'm glad the issue is already known.

++PLS

---