LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Could this create a race condition?

Hi,

Could a situation like this possibly create a race condition?



Test 1 vi updates a numeric (or indeed any other indicator)
Test 2 vi takes a reference of the numeric and reads the value.

Now test2.vi will run after test1.vi because of the error wire, but could it read the value before the numeric is updated?, ie does the updating of Numeric and the running of test2 happen in parallel?

I'm guessing that Numeric gets updated pretty quickly, and that calling test2 takes time so that a race condition is very unlikely.

Thanks
Dave


Message Edited by DavidU on 07-03-2008 08:06 PM

Message Edited by DavidU on 07-03-2008 08:06 PM
0 Kudos
Message 1 of 19
(3,129 Views)
The default value of Numeric will almost certainly be read while your first subvi is executing, so there will almost certainly be a race.
 
The behavior is best represented by the inputs "pushing" their values at subvis, not subvis "pulling" the values from the inputs.  Thus, the local will pass its immediate value to the second subvi, which will then wait for its error input to show up.


Message Edited by JeffOverton on 07-03-2008 03:15 PM
0 Kudos
Message 2 of 19
(3,119 Views)
The reference (hence the value) will be read immediately when the VI starts. The indicator will not be updated until the subVI finishes. Race condition for sure.
0 Kudos
Message 3 of 19
(3,113 Views)
Hmmm...  It seems like the value will not be read inside Test 2 until you execute the property node inside of Test 2.  With the overhead of the sub vi being much more (in comparison to updating the wire after Test 1) that there would not be a race condition.
SteveA
CLD

-------------------------------------
FPGA/RT/PDA/TP/DSC
-------------------------------------
Message 4 of 19
(3,110 Views)
Oh, I see your point because the value property is in the subVI.
0 Kudos
Message 5 of 19
(3,106 Views)
Whoops, that's not a local.  No, I don't think it would cause a race, and it hasn't the many times I've used it.
0 Kudos
Message 6 of 19
(3,102 Views)

This will cause a race.  Sub vi executes before numeric is updated



Message Edited by StevenA on 07-03-2008 01:30 PM
SteveA
CLD

-------------------------------------
FPGA/RT/PDA/TP/DSC
-------------------------------------
0 Kudos
Message 7 of 19
(3,100 Views)


StevenA wrote:

This will cause a race.  Sub vi executes before numeric is updated


Not necessarily. The subVI only gets the reference to the control, not the value. If the subVI reads the value property after enough time has passed, it will read the updated value. It all depends what's going on inside the subVI.
Message 8 of 19
(3,084 Views)


altenbach wrote:
Not necessarily. The subVI only gets the reference to the control, not the value. If the subVI reads the value property after enough time has passed, it will read the updated value. It all depends what's going on inside the subVI.


altenbach your correct.  This is what I was trying to illustrate with the trivial example shown.  It's a race condition if you execute the property node inside of Test 2 before 1 ms has expired (for this example).  Looking back at the original question, it is highly unlikley that you could get test 2 (with only the property node inside) to execute the property node before the update of the numeric out of Test 1.
SteveA
CLD

-------------------------------------
FPGA/RT/PDA/TP/DSC
-------------------------------------
0 Kudos
Message 9 of 19
(3,061 Views)
It is interesting because I had virtually the same code setup and it never caused me the race condition  up until I compiled the VI into an executable.  Based on my understanding of the dataflow your code will cause a race condition. The reason why you think the race condition is unlikely is because you think that code is executed from left to right which is not necceserily true. Labview will execute the code in such a way that  all ready inputs will propogate to their destination. In your case  the reference value is perfectly qualified to fire up its value at the very beginning of the program, even before the reference will be written to by test 1.  If you want to enforce strict dataflow you can use frames I guess. I hope this helps.





Message Edited by RSibagatullin on 07-03-2008 04:09 PM
0 Kudos
Message 10 of 19
(3,047 Views)