Sporadic failure of GetDetOffsetsMultiPeaks performance test

[Russell Taylor]

The error is:

In GetDetOffsetsMultiPeaksTestPerformance::test_performance:
/home/builder/jenkins/workspace/mantid_performance_tests/Code/Mantid/Framework/Algorithms/test/GetDetOffsetsMultiPeaksTest.h:166: Error: Assertion failed: offsets.isExecuted()

In the log you see this:

2013-02-07 15:15:11,855 [0] Notice GetDetOffsetsMultiPeaks - GetDetOffsetsMultiPeaks started
2013-02-07 15:15:11,896 [0] Error GetDetOffsetsMultiPeaks - Unable to initialise Child Algorithm FindPeaks
2013-02-07 15:15:11,896 [0] Error GetDetOffsetsMultiPeaks - PeakColumn - Unknown column name: "RunNumber"Peak column names/types must be explicitly marked in PeakColumn.cpp
2013-02-07 15:15:11,897 [0] Error GetDetOffsetsMultiPeaks - GetDetOffsetsMultiPeaks: Unknown property search object WorkspaceIndex
2013-02-07 15:15:11,907 [0] Error GetDetOffsetsMultiPeaks - Error in execution of algorithm GetDetOffsetsMultiPeaks
2013-02-07 15:15:11,908 [0] Error GetDetOffsetsMultiPeaks - GetDetOffsetsMultiPeaks: error (see log)

[Russell Taylor]

Digging into the log messages show that the init() method of FindPeaks is throwing (I'm not sure why exceptions in the initilize() method of child algorithms are captured when they aren't for top-level ones. Ideally, initialization should not be allowed to throw).

The 4th log message in the stack above shows that it throws before the WorkspaceIndex property has been created/declared.

The 3rd log message comes out of the typeFromName method in PeakColumn.cpp (line 65), and it's here that the problem lies.

What appears to be happening is that the first thread comes along and starts filling the map, but before it's finished a second thread comes along, sees that the map is not empty so skips the critical section and tries to use the map - but finds that the entry it's looking for is not there yet.

[Russell Taylor]

Re #6547. Add line termination so the log message will show up.

Changeset: 2f1f04864db4ee62ab66a3063f5c2ef87d0a1333

[Russell Taylor]

Re #6547. Check that map has been fully filled.

Just checking that it's not empty can mean that filling it is in progress, so we need to enter the critical block if that's the case. This shouldn't have much (any?) performance implication as size(), like empty(), takes constant time.

Changeset: e0a3cd29124dcc6356c3cb31976203d32c4477d4

[Russell Taylor]

Tester: As well as satisfying yourself that the code changes are correct (as always), the main test is that there are no failures of this test after build #2327:

​https://builds.sns.gov/view/Wall%20display/job/mantid_performance_tests/lastCompletedBuild/testReport/AlgorithmsTest/GetDetOffsetsMultiPeaksTestPerformance/history/?

I don't think this ever failed on the corresponding ISIS Jenkins job.

[Owen Arnold]

Code changes look correct in relation to the problem described.

Performance tests look very stable now.

[Stuart Campbell]

This ticket has been transferred to github issue ​7393