Global variable mutex when more than one front panel object in VI

[Les__Bartel]

Does LabVIEW put a mutex on the file (VI) or the object?

If the mutex is on the file, I will need to be more concerned with speed of access to individual objects in that file. This could require that I create more than one global VI.

My app has a high rate clock running (one writer) that needs to be accessed by several sub-VIs. I also have a small cluster with app configuration information requred by several VIs. It also contains a third 'quit' global.

The question is simple. Perhaps the answer is not.

[altenbach]

Please explain in more detail. 

What are "Objects" in the context of your question?

What do global variables have to do with front panel objects? (see subject line).

What are you actually trying to do?

What is a  "high clock rate" (Hz, kHz, GHz) and what determines it?

Is this on windows or on an embedded system?

Maybe you want to use data value references?

Can you attach some simplified code to explain better?

[Les__Bartel]

The objects are the controls on my globals.vi front panel (no block diagram). They are a cluster, boolean and U32. The U32 is the clock/counter which runs at a little less than 10kHz. Running on Windows, not realtime.

Using a data value reference is something I should consider.

The clock/counter is my timestamp on data going out in response to user input and data coming in vi ethernet. The clock will let me determine latency between a command and the response to the command. (Yes, TCP/IP has it's own latency.)

[Alexander_Sobolev]

Race conditions with global variables is a fact, LabVIEW does not have internal mechanism to lock access to them.

You can try to look at semaphores (synchronization pallette), you can prevent execution of different parts of code in parallel VIs using them. Then you can make read-write operation "unbreakable".

But why are you concerned with that? Single writer - multiple readers should not be a problem in any case: file, data value reference or variables. Open file.vi with Read Only access in readers and you can write to file (in writer) and simultaneously read its contents in several readers.

[Les__Bartel]

Based on what I've read (http://www.ni.com/white-paper/3898/en/), LabVIEW locks (via a mutex) access to global variables. My poorly worded question was whether LabVIEW locks at the global VI file level or object/control level. My global VI has three objects in it. If it locks at the file level, I can't access my clock while I'm accessing my cluster in another thread.

[GerdW]

Hi Les,

why do you think LabVIEW uses it's internal mutexes to protect shared resources? The linked article just explains a possible behaviour of "priority inversion" in the context of Realtime targets and time critical applications in case the programmer has created such mutexes…

- Globals aren't protected in such a way.

- Accessing globals simultanously from several instances can lead to race conditions.

- There are ways to protect access to global variables, but then you need to think about "priority inversion" too…

[crossrulz]

---

@Les__Bartel wrote:

My global VI has three objects in it. If it locks at the file level, I can't access my clock while I'm accessing my cluster in another thread.

---

Globals are so fast, you won't even notice on a Windows machine.  If you are really worried about it, recent benchmarking I have done shows that Single Process Shared Variables are even faster!

[Les__Bartel]

Ok, so globals aren't protected by mutexes. Are certain global writes atomic (value update cannot be interrupted by a context switch or simultaneous write from two different threads) operations and thus don't require a mutex to ensure an uninterrupted write? That is, if I have two threads writing to a global uint32, for example, is it possible for that uint to be partially updated and then a context switch comes along and the other thread updates the value, then the first thread resumes and completes its update? In the case of a cluster, I'm quite sure this is a possibility. It is obvious to me that when you have two writers to a global (in different threads) that a race condition exists and care must be taken to ensure proper behavior.

Are double precision floats atomic?

Extended precision floats?

U64?

Timestamps?

Anything more complex than these I would not expect to be atomic.

[GerdW]

Hi Les,

if I have two threads writing to a global uint32

You shouldn't have two writers accessing the very same resource at the very same time. Point.

Additionally it doesn't make sense to speak about "atomic writes" when you cannot assure the order of the write accesses!

In your sense all write accesses are "atomic", data will get written to the global. But in the very next moment your concurrent writer may overwrite the global with the next value…

Read about FGV (functional global variables) aka AE(action engines). They will solve the current issue!

[tst]

Access to globals is always atomic, regardless of how complex they are. If you have a cluster with 3 numerics and one place in the code writes {1,2,3} and another place writes {4,5,6} you will always have one of those two values. There will never be {1,2,6} or {1,5,3}.

The issue only happens when you have a read-write sequence, because then the value travels on a wire and you can have things happening in a different order. Every operation there is atomic, but the order of operations will affect the end result.