Setup and TearDown executed by different threads

vyazelenko at yahoo.com vyazelenko at yahoo.com
Wed Aug 13 11:41:38 UTC 2014


My use-case: start server in @Setup(Level.Trial) and shutdown server in @TearDown(Level.Trial).
And of course I want to setup some data for entire benchmark and remove it at the end.
In other words I'm looking for a way to perform per-Benchmark work irrespective of @State configuration.
And this work should be done by the same thread. In my case there is a session attached via ThreadLocal in @Setup.

I hope this clarifies the intent.

Best regards,
Dmitry

Sent from my iPhone

> On Aug 13, 2014, at 13:25, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
>> On 08/13/2014 03:06 PM, Dmitry Vyazelenko wrote:
>> I've found a problem in multi-threaded benchmarks that @Setup and
>> @TearDown are executed by different threads. This breaks the teardown
>> code, because it assumes that same thread that executed @Setup will 
>> execute @TearDown method.
> 
> If the @State is shared between the threads, you should not make
> assumptions about who actually accessed the @State object and its
> fixture methods.
> 
>> What I expect:
>> - For Scope.Benchmark single thread will execute all @Setup/@TearDown methods
>> (at least for Level.Trial and Level.Iteration, not sure about Level.Invocation though)
> 
> Ah, but that expectation is incorrect.
> 
> See
> http://hg.openjdk.java.net/code-tools/jmh/file/60e8aae7ac7d/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_05_StateFixtures.java#l50.
> 
> "As with the State, fixture methods are only called by those benchmark
> threads which are using the state." <-- That is, any thread which has
> the access to @State can call the fixture method. This is analogous to
> what you suggest from Scope.Group:
> 
>> - For Scope.Group probably use one of threads from the group? Or dedicated @Setup/@TrearDown
>> thread created in addition.
> 
> Is there a convincing use case that shows we should track
> @Setup/@TearDown callers for Scope.Benchmark?
> 
> Thanks,
> -Aleksey
> 


More information about the jmh-dev mailing list