This is caused by the `waitingNtolUpdate.waitOne()` call being at the end of the loop, not the beginning. The reason is that the `waitingNtolUpdate` is set during the first iteration (before the thread even gets loaded) - because the setter for Settings in this file sets it (and that's set by the setter for AssignPriorites.Connection, which is set in the HAWizard constructor). So when the thread first spawns we do the calculations, then get to the `waitOne` lock, which is set so we go back around the loop and calculate everything again before returning to the lock and waiting to be triggered. The correct behaviour is to trigger only once on the page load, and then only when re-triggered. To achieve that I've moved the `waitOne` call to the beginning of the loop, so that (assuming the `waitingNtolUpdate` lock is set before the thread is first started) we immediately run the calculations and then stop at the beginning of the loop waiting to be triggered again. This means that on page load (and after each re-trigger) we only calculate once.
The assumption that the lock is set before the thread is triggered is currently valid, because as mentioned above it's currently set by the setter for Settings which is indirectly called by the wizard constructor. I don't want to rely on that behaviour though because it's very indirect, so just to be safe I've added an explicit set just before the thread is triggered so that it's guaranteed to run the calculations the first time. This isn't strictly necessary but seems better than relying on the existing implicit setting. Since we use the same mechanism just in a different place, all the existing code that sets `waitingNtolUpdate` continues to trigger this thread as expected.
We observed that some threads can reach deadlock-ish state after they have Invoked into a control's UI thread. When it happens they are all in a waiting for join or in sleep state for very long time, although there should not be any deadlock situations.
It seems this has something to do with multiple parent controls and with which control we invoked on. This should not make a difference, because we have got one UI thread (for MainWindow) they should wait for, but we have seen it does.
The solution that fixed this issue was to invoke on the MainWindow instead of various controls (see a4fe507adf ).
This changeset is changing all our Invokes to invoke into MainWindow
instead of a control itself. (MainWindow's UI thread is the only UI thread
all Control is using in XenCenter)
This changeset should be in place until we have found the root cause or the exact reason for the above.
