avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Nasty Synchronization Bug in DefaultPool
Date Fri, 18 Oct 2002 00:18:26 GMT

Greg,

Thanks for the quick response.

>     Peter> i) Change the mutex so it isn't sensitive to the interrupt
>     Peter> status of the calling thread
> 
> You do want acquire() to be interruptible.

Why?  This is what I still don't quite understand.  Why should acquire
check the interrupt state of the calling thread?  I can easily imagine
the following situation.

Object obj = pool.get();

try {
  ... some long, possibly interruptible operation
} finally {
  pool.put(obj);
}

Why should the pool.put call fail if the thread has been interrupted?

>     Peter> ii) Move the m_mutex.acquire() call out of the
>     Peter> try/catch/finally block that contains the m_mutex.release()
>     Peter> call, have it record any error state, reacquire the mutex
in
>     Peter> case of error, and remove the object from the pool entirely
>     Peter> in the error case.
> 
> I say a variation of the above is a correct fix.

Ok.  Willing to buy that.

 
>     Peter> iii) Change the thread pool to reset the interrupt status
of
>     Peter> the thread being returned before it attempts to put it in
the
>     Peter> pool.
> 
> Looks reasonable, the pool can't rely on its users to return
everything
> in clean and dandy state.

I agree.  But DefaultThreadPool is a widely used class and we clearly
don't want to change its contract.  I'd want to clarify what the
contract is first.
 
> Anyways, could you try the patch I am attaching and see if code starts
> functioning correctly? It will still be throwing those harmless
> InterruptedException in case the thread is returned in interrupted
> state, but the corruption should cease (unless there are other places
> where the pattern is not used, last time I checked there were some)

The corruption ceasing is definitely good.

The patch you attach does resolve some of the problems - the mutex is
never corrupted and the IndexOutOfBoundsExceptions cease.  However,
size() continues to give the wrong answer since the interrupted thread
is never removed from the m_active list.  So we still get an eventual
failure if we have enough interrupted threads returned to the pool.

--Peter



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message