[Soot-list] Race condition in Heros

Eric Bodden eric.bodden at ec-spride.de
Fri Jan 25 08:39:53 EST 2013


Hello.

> It is a deadlock, actually. Most times, the analysis is over in a few
> minutes. In other times, it doesn't complete in >15 minutes, and my CPU
> usage is down. I infer from this that the analysis completed, but there
> was a race condition between the notify and the wait that make it so
> that wait never returns.

Oh, I see.

> Having worked with ExecutorService, the trick that I used was to load
> the executor up front with all the work units that needed to be treated,
> then call shutdown(), which will allow the backlog to be processed, then
> loop around awaitTermination().
>
> Obviously, that works only when you know for sure that you won't have
> more work units. I think the solver code I see there assumes that an
> empty worklist will stay empty, so that trick will work.

No, if the worklist is empty it may still be the case that tasks are
running that place items into the worklist again. That's why there's
the check numTasks.intValue()==0 before the return statement.

> IIRC, I needed to change the default queue, because the standard Java
> API was giving one with a bound in the number of jobs it would accept.
>
> You would have to use the constructor of the ThreadPoolExecutor instead
> of the convenience methods in Executors.

I am not quite sure how that would avoid a deadlock, though.

> P.S. I get this feeling that I've almost written the code here ;) I may
> have a bit of time later to work on a patch.

Ok, thanks!

Cheers,
Eric


More information about the Soot-list mailing list