I was working on a presentation for an internal user group and started playing around with race conditions and how to avoid them. This VI was the result.
So this VI has two FOR loops that each run 25 times in parallel. Each loop attempts to increment the variable by doing a Read, Increment, Write process. I did this using local variables, global variables, a Set/Get Functional Global Variable, an Action Engine with Get/Set/Increment actions, and a Data Value Reference. These two loops were ran 100,000 times and benchmarks were done out of curiosity on performance.
This VI also shows one of my pet peeves: the Set/Get FGV. As I have argued with people, you do not avoid race conditions just by using a FGV. In fact, you just made things worse by using the FGV over a simple Global Variable (just look at the execution times). It is only when you protect the entire Read, Modify, Write as an entire entity do you avoid the race conditions. Race Conditions and Functional Global Variables in LabVIEW
So feel free to try out my code. Tell me if I did something stupid or if there is something else you would like compared in here.
Code saved in LabVIEW 2014. The main VI is Race Conditions.vi
Revision 1: Added a case for Semaphores to protect the global variable to prevent the race condition. It should be clear that Semaphores are SLOW.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5