producer consumer (events) with cancel notification

[Blokk]

Hello,

Recently practicing LabView, and reviewing some of my older projects which are doing some measurements at our lab. In this example I have a quite simple task: continously get data (1 sec rate) from 2 Keithley multimeters (GPIB, 4 devices in case of calibration), and log it in tdms file if required.

I have the state machine in the consumer loop (shift register), and I use notifier with CancelNotification to check if there is new command from the GUI loop. I cancel it, so at the next iteration if there is no user interaction, the default (monitoring) case will be executed...

What do you think about this kind of approach? Please find the project in llb attached. How would you make it better? (it works OK, but I feel it is not optimal/elegant enough)

Thanks for any idea!

Regards,

ps.: in the used PC there is an old GPIB CEC pci card, no idea if this is the reason, but I got GPIB data read error from one of the Keithley, once or twice per day. I have realized that, a simple HW re-initialize made the Keithley communication working again, so I just detect and bypass this error as you see (since my DAQ speed is low, I do not care about if the soft reinits the HW a couple of times per day...)

[crossrulz]

To be a proper Producer/Consumer, you really need to use a Queue.  What you made here is actually a Master/Slave.

The difference is that the Master/Slave only cares about the last command that was sent.  If anything was already in the notifier and the master wrote over it before the slave got to read it, that data is gone.

A Producer/Consumer is a lossless architecture.  This means that every command sent by the producer is read by the consumer.

So I would highly recommend changing to a queue.  If you want to do something while "idle", then set the timeout.

[Blokk]

I understand that this is better to be called a Master/Slave pattern.

In this very example, why is it recommended to use queues over this notifier solution? I cannot imagine a scenario when any user input (click) could be lost. Since if the user starts data logging for example, there is a dialog window pop ups, and the notification is sent after choosing OK.

The user just does not have time to quickly click somewhere else to accidently overwrite the previous notification with another one...Am I not right?

[crossrulz · Accepted solution]

In my experience, you just never know what could happen.  I've seen Windows do some really weird things.  If you absolutely need every single command to go through, even if it is coming from the GUI, use a queue.

Also, what if you need another part of your program to command the logger.  You will have the GUI and the other thread competing for who gets their notification read.  A queue will not have that issue.

Even then, I don't really see the point of cancelling the notification.  If the Wait for Notification has already seen that notification, it will sit there and wait for another notification.  Again, you can use a timeout if you want to limit how long it should wait.

[Blokk]

thanks! It is clear now.