BatchRun only executes one run of a CrossValidation

[sforsten]

If CrossValidation is set as optimizer in a BatchRun, only the first run is executed. The BatchRun remains in the ExecutionState.Started and even if the BatchRun is stopped and prepared again, no additional run can be executed anymore.

The problem is that CrossValidation uses a lock in several methods, which are accessed through events by multiple cloned algorithms at the same time. The last algorithm which accesses ClonedAlgorithm_Stopped calls the method OnStopped which informs BatchRun that CrossValidation has stopped. Therefore, BatchRun prepares and starts CrossValidation again, which leads to the call of ClonedAlgorithm_Started by the algorithms started by CrossValidation.

The lock used in CrossValidation is acquired in the method ClonedAlgorithm_Stopped and the call hierarchy leads through BatchRun to the method ClonedAlgorithm_Started where the lock needs to be acquired again. This leads to a deadlock.

[sforsten]

r9493: the lock in ClonedAlgorithm_Started has been removed as well as all code related to the bool variable startPending. startPending is never really used. In the methods it is used, there is no chance that the if statement would evaluate to anything else than true.

One problem still remains. If the stop button of the BatchRun is pressed when its optimizer is going to be started for the next repetition, the BatchRun will be set to stopped, while the optimizer will start another run. When the optimizer is finished the BatchRun will be set to paused.

[gkronber]

The lock cannot simply be removed as it is possible that several threads call ClonedAlgorithm_Started in parallel. I'll try to fix the problem for the next release.

[mkommend]

Replying to gkronber:

The lock cannot simply be removed as it is possible that several threads call ClonedAlgorithm_Started in parallel. I'll try to fix the problem for the next release.

Yes you are right! sforsten and I have overlooked that the result collection is not thread-safe. An easy fix would be to introduce another lock object for access to the result collection, as the existing locker cannot be used due to deadlocks.

[mkommend]

r9504: Added lock object to synchronize access to the results collection.

[gkronber]

There are multiple usages of the results collection within the CV class and also potentially from other classes.

[gkronber]

r9517 minor adaptations in cross-validation

[gkronber]

Reviewed and tested r9504 and did not find any issues. Please merge the changes r9504 and r9517 into the stable branch.

[mkommend]

Reviewed r9517.

[mkommend]

r9525: Merged r9493, r9504, and r9517 into the stable branch.