Do you know the party game, “telephone”?  It’s where a group gets in a circle, and someone whispers a statement to the person next to them, who in turn whispers it to the person next to them, until the message gets all the way around the circle.  Invariably, the message gets corrupted along the way, and the statement at the end has lost all of its original meaning.  I find it both funny and sad.

The same thing seems to have happened with some information on race conditions and functional global variables in LabVIEW, so I want to try to clear it up.

It started earlier this week when I found an NI-internal document that’s used for code reviews, which said…

Functional Global Variables

A way to avoid race conditions associated with local and global variables is to use functional global variables. Functional global variables are VIs that use loops with uninitialized shift registers to hold global data.

· …

· The FGV eliminates race conditions

Whoa!  Given no context, that last statement is just plain wrong.

An internal document is one thing, but I’ve also heard this echoed by at least one customer in the past month, and also in an informal conversation here at NI.

What’s going on???  I decided to find out.  Keep reading to understand more about race conditions and how this game of “telephone” progressed to where we are today.

The LabVIEW Style Checklist

It gets worse.  Here’s a snippet from NI’s “LabVIEW Style Checklist” in the LabVIEW 2011 Help, where I’ve bolded part of the last, disturbing paragraph…

Avoid using local variables when you can use a wire to transfer data. Every local variable that reads the data makes a copy of the data. Use global and local variables as sparingly as possible.

Details

You can use global and local variables to write VIs efficiently, but use global and local variables as sparingly as possible. If you misuse or abuse global and local variables, particularly with array data types, the memory usage of the VI increases and the performance is affected.

You can encounter race conditions when reading from and writing to local or global variables in the same application. Race conditions are difficult to debug because there is no data dependency between different instances of the same local or global variable on the block diagram.

Consider using functional global variables instead of global variables. Functional global variables do not create extra copies of data and allow certain actions, such as initialize, read, write, and empty. They also eliminate race conditions.

Really?  Really?  FGV’s magically eliminate race conditions?  I’m starting to get upset.

With the help of Steve K., an NI AE Specialist, I started working my way upstream to find the source of this misinformation.  Steve pointed me to some NI training course material and some of the LabVIEW help.  I’ve started working my backwards through the circle to find out what was originally said, and how it got misinterpreted along the way.

LabVIEW Core 1 Training Course

Here, I think, is the ultimate source…  It’s our LabVIEW Core 1 training course.

The good news is that the material in the training class is written well and accurately; it’s at the beginning of the circle, before the message got corrupted.

I’m going to borrow some of the Core 1 content to explain some of the concepts and issues.  Lesson 9 is about using local and global variables to communicate information between parallel loops. It then covers the concept of race conditions, and uses an example like this…

Consider what happens if the loop operations happen in the following order:

1. Loop 1 reads the global variable.
2. Loop 2 reads the global variable.
3. Loop 1 increments the value it read.
4. Loop 2 increments the value it read.
5. Loop 1 writes the incremented value to the global variable.
6. Loop 2 writes the incremented value to the global variable.

In this case, the count variable gets incremented by one, even though it was accessed twice.  Just to be clear, LabVIEW could also choose to execute the same VI like this…

1. Loop 1 reads the global variable.
2. Loop 1 increments the value it read.
3. Loop 1 writes the incremented value to the global variable.
4. Loop 2 reads the global variable.
5. Loop 2 increments the value it read.
6. Loop 2 writes the incremented value to the global variable.

And since this is all happening in parallel threads, possibly on two separate cores, the exact interaction between loops 1 and 2 can vary from iteration to iteration of each loop.

This is “correct” behavior from LabVIEW’s perspective; the diagram doesn’t specify any order dependency between the two loops, so it doesn’t impose any.

But probably, you want the “read, increment, write” to happen atomically—as if it were a single operation that could never be interrupted.  This is such a common thing to need to do that CPUs actually have this built in as a machine instruction.  It’s very important for avoiding race conditions across multiple CPUs in a system.

Critical Sections

LabVIEW Core 1 introduces the concept of critical sections. A critical section is a piece of code that accesses a shared resource that must not be concurrently accessed by more than one thread of execution.

The “read, increment, write”, then, is a critical section.  You want to ensure that those three things happen atomically—without interruption.  Continuing with the material from Core 1…

One way to protect critical sections is to place them in subVIs. You can only call a non-reentrant subVI from one location at a time. Therefore, placing critical code in a non-reentrant subVI keeps the code from being interrupted by other processes calling the subVI. Using the functional global variable architecture to protect critical sections is particularly effective, because shift registers can replace less protected storage methods like global or single-process shared variables. Functional global variables also encourage the creation of multi-functional subVIs that handle all tasks associated with a particular resource.

Great.  FGVs are a good way to protect a critical section, which in turn can eliminate race conditions.

Action Engines

I want to be especially clear that the FGV must contain the critical section for it to eliminate race conditions.  In our example above, the critical section was “read, increment, write”.  If you had an FGV that just did “read” and “write”, it wouldn’t protect the critical section.

Action engine is a term that was created to describe a special kind of FGV where it does more than just read and write to data storage.  An “action” can be anything.  In our example, it’s “read, increment, write”.  We could have other actions, such as modifying a file, updating a database, performing I/O; anything we wanted to protect from executing in multiple threads at the same time.

So unlike simple variables, which can just read and write, an action engine can perform a more meaningful action which includes the entire critical section that you want to protect.

We cover this in the LabVIEW 2011 Help, in a section on “Using Local and Global Variables” in a discussion about “read, modify, write”…

Race conditions also occur when two operations are trying to update a global variable in parallel. In order to update the global variable, an operation reads the value, modifies it, and writes it back to the location. When the first operation performs the read-modify-write action and the second operation follows after, the outcome is correct and predictable. When the first operation reads and then the second operation reads, both operations modify and write a value. This action causes the read-modify-write race condition and produces invalid or missing values.

You can avoid race conditions associated with global variables by using functional global variables. Functional global variables are VIs that use loops with uninitialized shift registers to hold global data. A functional global variable usually has an action input parameter that specifies which task the VI performs. The VI uses an uninitialized shift register in a While Loop to hold the result of the operation. Using one functional global variable instead of multiple local or global variables ensures that only one operation executes at a time, so you never perform conflicting operations or assign conflicting values to stored data.

Here, the word “operation” is more or less a critical section—a “read, modify, write” action.  I am a little troubled by the first sentence of that second paragraph just above…

You can avoid race conditions associated with global variables by using functional global variables.

If you remove the context of a “read, modify, write” critical section, it will be misinterpreted.  Here’s an example…

LabVIEW Core 3 Training Course

As we sometimes do in our training material, we revisit earlier topics when they’re relevant to new material.  The LabVIEW Core 3 class includes this paragraph in a discussion about Information Hiding… [emphasis is mine]

Functional Global Variables

You can use uninitialized shift registers in For or While Loops to hold data as long as the VI never goes out of memory. The shift register holds the last state of the shift register. A loop with an uninitialized shift register is known as a functional global variable. The advantage of a functional global variable over a global variable is that you can control access to the data in the shift register. Also, the functional global variable eliminates the possibility of race conditions because only one instance of a functional global variable can be loaded into memory at a time.

Oops, we misplaced a bunch of context about critical sections and actions.  FGVs can protect critical sections, but they do not inherently eliminate race conditions.

Summary

I might summarize like this…

If you have an FGV which is an action engine which protects a critical section, you eliminate race conditions associated with that critical section.

I might also simplify it to this…

Functional Global Variables are a good way to protect critical sections.

I suppose I should have started with a discussion about whether you even need to use global or local variables.  If you don’t have information that needs to be shared across threads, you probably shouldn’t be using them.  All of this is discussed better in our Core 1 training material.

Speaking of which, I like to think that someone who had gone through our training courses would have known the caveats that go along with the statements above that talk about how FGV’s eliminate race conditions.  If you haven’t taken our training, I encourage you to visit http://www.ni.com/training/, and I bet you’ll find some courses that will be valuable.

Thanks for reading this far.  I’d be curious, if you’re willing to confess in the comments section below, if my information about FGVs, race conditions, and action engines is new to you and if it’s helpful, or if you think there’s anything unclear or something I’ve forgotten to cover.