Leaderboard

I created two new nodes in LabVIEW. Really neat, eliminated a problem I was having where the existing G solution was too slow. Then I discovered that one of the nodes inadvertently created a hole in the protections of both VI Server security and library encapsulation. So I patched that. And now it was slower than the original solution. I feel like Dr. Frankenstein having to shoot his own creation just because it started eating a few villagers. *sigh* Back to the drawing board...

Just so everyone is clear: Using the Not A Refnum function to decide to create a refnum is ok because the zero refnum cannot be destroyed/released in a parallel thread. But since the primitive does the extra work of validating the refnum, you take a performance hit on the cases that are going to succeed. Using the Not A Refnum function to decide to do an action or not is a race condition because a parallel thread could be destroying that refnum in between the test and the action. If you need to actually do an operation, do one of these: If you need the combined behavior of "if the refnum is bad, allocate it, and do some operation on it", then do this: What is an acceptable use case for the Not A Refnum primitive? When you're evaluating the status of one refnum before taking an action on another refnum! Or if you're just displaying information in a Custom Probe. Or if you have absolutely nothing happening in parallel (in which case, you might reconsider your use of references anyway). (For advanced users who suggest the use of semaphores to protect the access, that counts only as an OK usage because you still have a performance hit of unlocking and locking the refnum twice.) If you ever are tempted to file a bug report that the LabVIEW queue functions are broken, please check your use of Not A Refnum first. I guarantee I will when the bug report gets to me. 🙂 And, for the record, all of the above also applies to using "Get Queue Status" and "Get Notifier Status" functions. And any other similar "is this refnum still valid" functions that you are using to make decisions in code.

Hi Aristos, is the last "COMBINED GOOD USAGE" correct? I would expect, that in case of error on Enqueue element, I would create a new queue... Jiri

One of the dangers of jumping straight into the Actor Framework is you can end up writing code without understanding the subtleties or impact of your design decisions. In some respects that's what has happened with the QSM--it's super easy to write relatively complex code that on the surface looks great, but it's also super easy to create an unholy mess of things, and most people who use it don't understand what issues they should be looking out for. From what I have seen of the AF it is nowhere near as error-prone as the QSM. It may turn out my concerns are unfounded. I actually hope that is the case. However, for better or worse the AF appears to be on the cusp of becoming the next QSM for the LVOOP crowd (meaning commonly accepted as a one size fits all solution,) and given all the crazy problems I've seen with QSM implementations that worries me. Assuming you already understand OOP fundamentals (and it appears you do,) Head First Design Patterns is the first book I recommend for people starting to learn how to design OOP applications. After that the list opens up quite a bit. (Object Thinking, Design Patterns, The Object Oriented Thought Process, Practical API Design, etc...) Personally, I'd avoid using exam examples as the basis for anything other than learning how to pass the exam. Constraints imposed by the exam conditions (like the time limit) can lead to short-term design decisions that are not immediately clear to users unfamiliar with OOP, and those decisions might not be compatible with your requirements. I know I wasn't particularly happy with the code I turned in for my CLA exam. (Mostly... I thought the code was great on the exam I failed. I thought the code sucked on the exam I passed.) That said, I have not looked at AQ's sample test implementation. It may be a beautiful example of how to design a sustainable LVOOP application. *shrug*

In 2011 (not sure about 2010) the VI hierarchy window can help draw your dependency map for you. There is a "Group Libraries" button that will put all VIs in a library together. Cycles between your libraries then show up as backwards dashed references. You can even collapse each library to a single item. This does mean you have to load all your VIs into memory to get the full graph, but it works. I wanted this feature way back when we introduced libraries but it took a while to get it.