Sending interrupts to the worker threads upon teardown

[Nitsan Wakart]

The queue problem is for asymmetric threads(different methods are called) but required to be called exactly the same number of times to complete successfully. A perhaps naive solution would be:
start..
while(dummyVolatileAlwayTrue && ops < SAMPLES)
{ doIt(); }
end..
There would be a start/end jitter, but the more samples you have the less significant it should be.  The dummy volatile should prevent unrolling. SAMPLES is a magic number.

> On Apr 15, 2014, at 7:20 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
>> 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.