[Soot-list] Race condition in Heros

[Eric Bodden]

... and another possible solution seem to be semaphores:
http://stackoverflow.com/questions/6585337/calling-object-notify-before-object-wait

Eric

On 25 January 2013 14:42, Eric Bodden <eric.bodden at ec-spride.de> wrote:
> Hi again.
>
> It just occurred to me... I think the problem can only occur if
> notify() happens before the wait(). Unfortunately, that's something
> that's hard to control. Hence I wonder whether one should not just
> give a timeout to the wait(..) call, say, one second or so. That would
> cause the loop to wrap around at least once a second and should allow
> normal termination that way.
>
> Eric
>
> On 25 January 2013 14:39, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>> 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
>
>
>
> --
> Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
> Head of Secure Software Engineering Group at EC SPRIDE
> Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt



-- 
Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt