Hi All, I am developing an application where a 'control' subVI is accessing an 'action' subVI. The action subVI is actually accessed by a number of different high-level subVIs to I definately need to use globals. I wrote the following piece of code and was struck that it might lead to a race condition. Essentially my control subVI runs two loops in parallel. Each loop reads the global, increments a different value in each one, waits a set amount of time and then returns the value to its previous value. I've written this piece of code to demo what I'm talking about. The Waveform chart takes the place of the 'action' subVI. Running this code has resulted in a race condition (one of the values goes from 0-5 range to 5-10 range) after being loaded into memory running a second time usually lets it run for a long time. I modified the VI to exaggerate the effect of the race-condition for demonstration. I also implemented a solution by using a local variable to stop the globals being accessed at the same time. However it is far from elegent and I don't think it will work for more than two loops. I eventually need to use three loops. I've attached my exaggerated demo/solution. If you can suggest a better way to solve this problem I'd be much obliged. Thanks,Dave

DeltaJ wrote: I just walked out of the lab for some fresh air - after staring at this problem for hours - and it hit me. If I write access to my Globals within a subVI - which I can do - and make the VI reentrant won't the program only be able to access the globals in sequence and avoid the race-condtion that way? A reentrant VI uses its own separate memory space for each instance so it means it can be called in parallel with another instance. This means it just gives you the same situation as what you currently have. Or do you mean I can queue access to the global - I may be able to do that without a huge re-write! No, I wasn't talking about queueing access to the global. I was talking about storing the data in a queue. Encapsulating the updating of the value in a subVI is what you would do with an Action Engine. Note that you want an "update" action so the read/write occurs inside the Action Engine VI. This will give you as close to an atomic operation that you can get.

LabVIEW

Locking access to Global Variables to avoid race conditions??

Solved!

Author

Hi Ben/Smercurio

I just saw your follow-up posts today - thanks for the additional info and I'll definately follow up on these two approaches! I've already re-written some of the code to get rid of the globals.

Thanks again,

Dave

Message 11 of 11

(587 Views)

LabVIEW

Locking access to Global Variables to avoid race conditions??

Re: Locking access to Global Variables to avoid race conditions??