Sending interrupts to the worker threads upon teardown

[Aleksey Shipilev]

On 04/14/2014 10:56 PM, Chris Vest wrote:
> Yeah… both are wrong. And there is no way for the harness to know how
> much work did or did not get done, or how much time was spent blocking.
> I was guessing that the synchronised iterations would magically take
> care of and exclude these kinds of outliers at the beginnings and the
> ends from the measurement, but I guess that was a misconception?

Yeah, the trouble with that idea is that we really finish all the
threads after each iteration, i.e. all threads have to leave the
measurement loop body. Therefore, each iteration would have its results
contaminated with unlucky samples. We can think about doing the seamless
iterations, i.e. the iterations what stay within the generated loop
though...

> I’m not sure just specifying the order in which the threads leaves the
> measurement is enough. In the case of SynchronousQueue, put() will block
> if there is already an item enqueued. So when the taker leaves, the
> putting thread has to stop before it can do two puts in a row.

Aw, nice counter-example, thanks! So much for the leave order idea.

-Aleksey.