lttng: Make ZoomThread more thread-safe (also helps ResourcesViewTest)
authorMarc-Andre Laperle <marc-andre.laperle@ericsson.com>
Tue, 12 Apr 2016 19:38:02 +0000 (15:38 -0400)
committerMarc-Andre Laperle <marc-andre.laperle@ericsson.com>
Wed, 13 Apr 2016 21:03:03 +0000 (17:03 -0400)
commit6d28f3e811a00bfb4bda9282fbb095040da9674d
treeb3ef5ca76551fbfb3e1f58a9dc50ef2f9692cf1a
parent9a869f27883255582a805c7001118eb7a0d07c79
lttng: Make ZoomThread more thread-safe (also helps ResourcesViewTest)

In AbstractTimeGraphView and extenders, when a ZoomThread applies its
results (links, markers), there is no guarantee of the order in the
presence of multiple ZoomThreads.
For example, in the case where a new ZoomThread is started and an old
one is still executing, the old one might be canceled so late that it
will still apply its results and do so *after* the new ZoomThread
completes. This change introduces some synchronization to make sure the
results are applied only in the case of the last ZoomThread spawned.

To reproduce this issue, go to AbstractTimeGraphView.getTraceMarkerList
and add a Thread.sleep(5000); before and after the isCanceled() check.
Because the test takes much longer, you need to increase the timeout in
ResourcesViewTest.timeGraphIsReadyCondition. Then you can run
ResourcesViewTest in a loop using SWTBotStressTests and after a few
iterations, it should fail.

Change-Id: If41f7b264676c04538cdc39c5c9bb40507b7e521
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/70510
Reviewed-by: Hudson CI
Reviewed-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
tmf/org.eclipse.tracecompass.tmf.ui/src/org/eclipse/tracecompass/tmf/ui/views/timegraph/AbstractStateSystemTimeGraphView.java
tmf/org.eclipse.tracecompass.tmf.ui/src/org/eclipse/tracecompass/tmf/ui/views/timegraph/AbstractTimeGraphView.java
This page took 0.025503 seconds and 5 git commands to generate.