[concurrency-interest] ThreadPoolExecutorTestoccasionallyfailswith a broken barrier!?
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.
> -----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:
> 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)?
More information about the Concurrency-interest