How is this race condition considered fixed with FGV ?

[zigbee1]

Hello, 

Below from an NI design pattern talk, it is illustrated that FGV with atomic action can eliminate race condition in two loops. But the way I see it, it is still the same. There is still a condition that when mode is read as Current in the 2nd loop, before the 50ms lapses, the 1st loop sets the mode to Voltage, then after that 2nd loop sets value (Mode = Voltage, Value=Current).

[perhult]

I agree it is kind of a silly example, but you are not seeing the internal logic of the FGV in your image. You are not seeing how the program is displaying or is treating the "values" either.

A race condition is often defined as an undesirable action when a system performs two actions at the same time when the actions needs to be done in a certain order.

If the problem in the first example is that you are making a "Voltage" measurement when the user has already requested a change to "Current" measurement and that that is not desired, the FGV could as an example simple disregard setting the value if the mode has been changed after the mode was last outputted. If that is what you think is the correct action, of course.

The appropriate action of the FGV depends on the application requirements.

[zigbee1]

This is the implementation of FGV, as you can see, it is no difference than writing and reading from a global variable. The content of this webcast is from "LabVIEW Design Patterns Mini-Series - Singleton"

[Artem.SPb]

for example cluster:
volt = 10
current = 1.3

Left:
- read volts and whole cluster (10, 1.3)
- update one element (10, 2.9)
- here upper loop can update cluster (12, 1.3)
- write new cluster value (10, 2.9)
finally you lost volt = 12 because you write wholle cluster after update

Right:
in FGV you update one element at time because you can't call FGV in parallel (reentrant is off). While one "clone" works, another clones waits.
So
1) read volts
2) calculate current
3) update only current in FGV (and don't touch volts)

[natasftw · Accepted solution]

The short answer is, you're right.

The implementation of the FGV doesn't matter.  The fact the FGV can only be called once doesn't matter.

A race condition is something that takes place when you can't guarantee the order of execution.  The same exact code can result in multiple outcomes with different runs because of the randomness of multiple thread processing.  The problem still exists with those.

The problem stems from the way the FGV is taught in LV.  It's taught as a way to help eliminate race conditions as you can only call it in a single place.  This prevents multiple places in your code from writing at the same time.  It does not resolve the underlying problem, that two places in your code can write to that at indetermininate times roughly being equal.

In both sides of that example, it's bad programming and should be avoided.  The benefit you've gained by going to the FGV is offset by the terrible practice of writing to it in both locations.

The reasons others mention implementation is the code can add more possible outcomes with a more complex implementation.  If you run a series of calculations pulling from variables prior to moving to the FGV, you can eliminate these calculations from being changed halfway through.  But, you still run into the problem where you don't know which of the two loops will write to the FGV first so you're still racing to it.

[zigbee1]

It is what I thought. Thanks !

[billko]

It is misleading when they talk about FGs reducing the chances of race condotions.  Instead, maybe it should be said that it is easier to enforce execution order than with a global variable because you (usually) have error terminals.

[crossrulz]

1.  I actually make a distinction between an Action Engine and a Functional Global Variable.  A FGV is just an AE with just a Set and Get conditions.  What you have shown is a FGV.

2.  Functional Global Variables do NOT eliminate any race conditions.  In fact, I actually consider them evil.  Global Variables are much faster.

3. Action Engines prevent the Read-Modify-Write types of race conditions by protecting the "critical sections" of code.  This takes care of a very large percentage of the race conditions I have ran into.

Shameless plugs for additional information:

A Look At Race Conditions

Are Global Variables Truely Evil?