After 10 years of LabVIEW development, I like to think of
myself as fairly experienced. I’ve acquainted myself with a number of design
patterns. When I encountered this, I assumed I was dealing with an event-based producer-consumer pattern.
Do you spot what’s wrong with this picture? Technically nothing, but it took me a
minute to figure out what was really going on with that queue. That’s right,
it’s not really a queue. It’s an elegant hack to control timing and shutdown of
those parallel loops. My first reaction was, “this is wrong
,” but the best I could do to justify that judgement was that
this isn’t what queues are supposed to do. Problem
Readability. I didn’t understand what was going on as quickly as I would
have with a more conventional use of a queue.
Weeks later, I was troubleshooting a problem with a similar
implementation. Do you spot the problem here?
Kudos if you caught that the bottom “Status Loop” was
gobbling up data intended for the Action loop. Someone took the pattern for
timing and shutting down parallel loops and leveraged it to also carry data. Problem 2:
Protection. There isn’t a
guarantee that someone won’t mess with your queue.
using this pattern, you must be sure to wire in a timeout value. Otherwise,
your loop’s not gonna loop.
In the interest of continuous improvement, I thought we
could add an improved version to our arsenal. One that solves all the problems.
We call it Exitimer
, and it’s just a class wrapped around the queue
a little VI documentation, other developers understand what Exitimer’s being
used for. It’s a timing and shutdown mechanism. They don’t even have to think
access scope to the queue is limited, nobody can try to misuse it to carry data.
the timing input is required and negative numbers are handled, there isn’t a
risk of an infinite timeout.
Labels: Endigit, LabVIEW, Tips & Tricks