Sending interrupts to the worker threads upon teardown

[Aleksey Shipilev]

Unfortunately, this breaks steady state in benchmarks, and breaking
steady state is far worse than omitting/including a single op.

-Aleksey.

On 04/15/2014 10:31 PM, Nitsan Wakart wrote:
> 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.