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