null check postPhase
in Worker.run
to resolve race condition at terminate
#211
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ThreadBench
andWorkloadState
rely onWorkloadState.currentPhase
beingnull
as the indicator that the benchmark is over. For example:benchbase/src/main/java/com/oltpbenchmark/WorkloadState.java
Lines 205 to 206 in 1c43cad
However,
Worker
relies onBenchmarkState.state
beingDONE
as its indicator that the benchmark is over. For example, this switch assumes that because state is stillMEASURE
that the benchmark is still running and that the result ofgetCurrentPhase
is safe to access:benchbase/src/main/java/com/oltpbenchmark/api/Worker.java
Lines 288 to 296 in 1c43cad
The race occurs between the previously mentioned switch in
Worker
and inThreadBench
where this line advances to the next phase, which in the case of the benchmark ending, puts the current phase tonull
. If aWorker
tries to read the current phase before the state is set toDONE
whenThreadBench
callsstartCoolDown()
then benchbase goes boom.benchbase/src/main/java/com/oltpbenchmark/ThreadBench.java
Lines 222 to 229 in 1c43cad
I believe the easiest fix here is a documented
null
check inWorker
. Maybe there's a better way to sync up the indicators of the benchmark ending between all of these classes, but this seems like the lowest risk change.Fixes #37.