[concurrency-interest] ThreadPoolExecutorTestoccasionallyfailswith a broken barrier!?

Oliver Pfeiffer pfeiffer at tzi.de
Wed Feb 14 06:33:28 EST 2007


You're right there is no need to pass the task by submit() instead execute()
should be used to avoid the future encapsulation. Anyway this doesn't make
any difference -> the test still fails with the same ratio.

Oliver


> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu 
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf 
> Of Joe Bowbeer
> Sent: Wednesday, February 14, 2007 9:45 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: RE: 
> [concurrency-interest]ThreadPoolExecutorTestoccasionallyfailsw
> ith a broken barrier!?
> 
> 
> Maybe, every so often, it takes more than 1 second to execute 
> the first 17 tasks?
> 
> What happens if you change the barrier timeout to 2 seconds?  
> Do the failures vanish?
> 
> 
> On 2/14/07, _Oliver Pfeiffer_ <<pfeiffer at tzi.de>> wrote:
> 
> > The barrier should check that a total number of 17 threads (16 + 1) 
> > are able to touch it in parallel. Thus all further threads arriving 
> > later do not need
> > to pass the barrier.
> > 
> > The occasionally thrown AssertionError comes from the 
> broken barrier 
> > as checked by assertFalse(barrier.isBroken()); at the end 
> of the test
> > method.
> > 
> > Future#get() isn't called after submission since an 
> exception should 
> > never be thrown in the runnable as long as latch#countDown() is 
> > harmless. :)
> 
> 
> 
> But Errors can still escape.  And RuntimeExceptions and 
> Errors can potentially escape from execution of countDown.  
> Why not execute(Runnable)?
> 
> --Joe 
> 




More information about the Concurrency-interest mailing list