keeping objects in action engines or globals?

[DFGray]

I am late to this party, but would like to make a few points (some of which have already been made).

1. Globals are generally the fastest mechanism for "look-up table" like functionality.  However, they are not safe.  You cannot enforce write-once-read-many behavior.  You cannot enforce thread safety.  They rely on the discipline of the coder to be safe.  I never use them, since I cannot guarantee that I will be the only one maintaining the code I am currently working on.
2. DVRs are much safer.  However, in complex situations, their overuse can result in thread thrashing as they lock and unlock things in multiple threads.  They are almost as fast as globals.  They also scale much better than action engines.  This used to be my method of choice.
3. LabVIEW is a data flow language, so a well designed program will use that.  Over the years, I have come to the conclusion that globals, DVRs, AEs, and single-element queues, etc. are usually an attempt to get around the use of data flow rather than design with it in mind.  Data flow programming is much different than sequential programming.  For simple things, the differences are small.  For large programs, the differences can be huge.  You can write a large program with virtually no DVRs/AEs/Globals, but it takes a fair amount of up-front planning.  In the end, you get a very modular, loosely coupled system that is a pleasure to use and debug.  Check out the actor framework for a modern look at LabVIEW system design.  I realize you can't do this easily if you are trying to upgrade old code, so would recommend DVRs, as you are currently doing.

Good luck with your refactor.

[QFang]

Thanks for joining us, the more the merrier!

-My long term goal is to completely re-design and re-architect the application using the MCV Actor pattern as described here as my starting point. I've been doing a fair bit of reading to catch up on the OO theory and vocabulary as well as UML 2.0 and have already started trying to design the "next evolution" while hacking and fixing what needs doing on the old architecture in the mean time. -I'm so fortunate in that our company is encouraging spending work time building these skills and re-designing and re-doing this program, we just need to get something into a closed beta with a high profile customer. This "open beta" as we call it internally, is anticipated to be more of a proof of concept for the customer, so I can get away with taking some shortcuts.

Anyway, rambling on.. time for lunch! 

[Ben]

Go for it Q!

take notes to share with us anything you learn along the trail.

Ben