Continuous Measurement and Logging Template - May hang-up due to lost Exit

Question

The template Continuous Measurement and Logging in LabVIEW 2012SP1 has a flaw in the both the Acquisition and Logging loops.
The Stop message handler discards all messages in the message queue. The note says:
"Stop - Flush the queue of any pending "Log" messages. Close the TDMS file reference." See picture below.
This concept breaks if the Exit message is posted while the Stop message is being processed. The Critical time gap for this to happen is small because Exit is posted to the front of the queue. But it depends on the processing in the Stop handler case. Small or large - it can happen.
The symptom is that the application hangs in an infinite wait on the message queue - all controls are with no effect as the rest of the loops are terminated. Only Break will terminate the application. Pause button does not work either. (see this forum entry)
This problem may only appear after the application has become more complex and the timing has changed - the fresly made template works and does not reveal the issue.
The cure: First I thought of previewing the queue elements before discarding them selectively, one by one in the Stop loop, but that wont work either, because the Exit may arrive precicely in the time laps between preview and dequeue - remember Exits are posted to the front of the queue.
I think the best option is to replace the flush of the queue in the Stop message handlers with a Selectively dequeue of messages one by one and check each if Exit is found - if so, re-insert it into the front of the queue. All other messages are discared. This look like this, having the interesting parts visible...
Below is what the Stop message loop looks like with the problem highlighted.
Given that I am not mistaken, I think it is better that NI updates the templates to prevent this problem.
Solved!
Go to Solution.

Answer 1

Here's what the idle state case within the stop message case looks like:
We don't hang the CPU handling a constant stream of no-op messages because we only enqueue "Log" messages when we are in the valid logging state (the Idle state here is again a passthrough).
The worst case scenario is that there are number of Log requests already in the queue when the system stops. Upon recieving the Stop message the state transitions to idle and the remaining Log messages become no-ops due to the state.
I will look into the feasibility of posting some updated VIs.
~Simon