I'm just going through the solution and I spotted the following:
As you can see, when the consumer loop is exiting it call the producer telling it to exit. The producer runs it's exit case which calls the consumer loop again even though the consumer should have stopped.
I certainly wouldn't code something like that intentionally but maybe I am missing something vital, is that an error in the solution or have I read the logic wrong?
Solved! Go to Solution.
The producer loop doesn't "call" the consumer loop, it just enqueues a new states towards the consumer. If the consumer loop canoot dequeue then it just doesn't...
Both loop condition terminal is wired to a TRUE constant so they both stop immediately.
What if the consumer loop stops? This could happen in the case of an error. If you don't have the consumer loop firing the event for the producer, then the VI "hangs".
If I am not mistaking, in this sample exam any error generated in a consumer of any module is handled that way: the concerned consumer enqueues a new state in the Error Handler module queue. Once dequeued, that state fires a user event so that every module generates its dedicated exit procedure.
I get your point Fabiola but from what I see here, it is OK. It may not be the best way to achieve that but it should work. Once again I may be wrong and I would be happy to get some explanations if that's the case
Create a project using the National Instruments Queued Message Handler and study how they exit the application. You will see it is the same approach.
Thanks Fabiola/ Maxine,
I don't know how I didn't spot the fact the consumer 'Exit' case is not calling the producer, maybe more sleep required! It doesn't really make sense to me that the exit case would fire an abort user event when the error handler should be generating the user event. I'm still trying to get my head around this architecture!
So in summary, the error handler will tell producer to stop via the error handler but a situation where the consumer loop fails might cause the system to hang.
Actually, this may be the reason why I was confused:
As you can see in the above, the consumer and the user event is called by the controller (looks like a type of race condition). This means the consumer could then call the user event which would then call the consumer that had already stopped.