LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Could this create a race condition?

It is really a race of OUTGOING wires.  If the error wire coming out of subVI 1 sends its data onto subVI 2, which now has all of its inputs as the reference was already passed to it, and it executes the code to get the value of the reference, BEFORE the data coming out of subVI 1 on the blue wire arrives at the terminal of the indicator, then yes you would have a problem.
 
Though it seems like an unlikely situation, it would all depend on the way the code compiles and the way it handles buffer allocations and moving data around in memory.

This is an interesting thread and seems to talk about a different aspect of race conditions from the usual threads where people are posting code that is just competing local variables.

Message Edited by Ravens Fan on 07-03-2008 05:19 PM
0 Kudos
Message 11 of 19
(757 Views)


Ravens Fan wrote:
It is really a race of OUTGOING wires.  If the error wire coming out of subVI 1 sends its data onto subVI 2, which now has all of its inputs as the reference was already passed to it, and it executes the code to get the value of the reference, BEFORE the data coming out of subVI 1 on the blue wire arrives at the terminal of the indicator, then yes you would have a problem.
Hi Ravens Fan,
 
I think I dont get your point. Smiley Indifferent
 
Did you meant that there is a chance that the Error Out terminal of SubVI1 may give its (default)output to SubVI2 before SubVI1 has finished its execution?
 
Please make me a bit clearer...
- Partha ( CLD until Oct 2024 🙂 )
0 Kudos
Message 12 of 19
(734 Views)


parthabe wrote:

 
Did you meant that there is a chance that the Error Out terminal of SubVI1 may give its (default)output to SubVI2 before SubVI1 has finished its execution?
 


No. Not at all.
 
Usually, we are talking about race conditions as they deal with local variables.  One section of code is ready to execute and read a local variable before another section of code has a chance to write an updated value to another copy of the local variable.  Or two sections of code battle as they both try to write to a local variable.  One wants to write true to a boolean while another wants to write false.  Whichever writes its data last effectively wins.
 
This is more about the wires.  It is true that none of the other code can execute until the 1st subVI completes.  The numeric indicator requires a value coming in on the blue wire.  The 2nd subVI requires the data of the control reference and the data from the error wire.
 
When the 1st subVI completes, it has a numeric value sitting on its output connector pane, and an error cluster sitting there as well.  Is that numeric value instantly entered into the numeric indicator?  Or does it take another CPU cycle to transfer that data from the subVI to the numeric indicator?  (I imagine whether memory needs to be copied and buffer allocations come into play here.)
 
Let's say that data isn't instantly transferred from one end of the wire to the other.  The CPU could schedule the 2nd subVI to run and complete some or even all of its execution because the error cluster and the control reference are both available at its connector pane, before the CPU has decided to update the numeric indicator with the value that has come out of the 1st subVI.  The execution of the 2nd subVI is not dependent on the fact that the indicator has been updated, really only that the 1st subVI has finished.
 
If data isn't instantly transferred from the source of the wire to its destination,  then there is a possibility of a race condition based on how fast the data flows down the wires.
 
I hope this makes my line of thinking clearer.  I never really thought about it in this way until I started reading this thread.
Message 13 of 19
(713 Views)

If the Value property is read inside the second subVI, then there is a race condition without any shadow of a doubt.

You should note that a race condition is a condition - it isn't about whether you actually saw the code behaving not like you want, but whether the code might behave in that way. Even if you added a 10 second wait in the second subVI before reading the property, there would be nothing to guarantee that the calling VI would not wait 12 seconds before updating the indicator. As such, you can't expect to see race conditions by running the code - you need to learn to avoid them and recognize them if you see them.

There was even an example mentioned in this thread - the code works fine in the IDE, but there were issues when the code was built into an executable.



Message Edited by tst on 07-04-2008 09:26 AM

___________________
Try to take over the world!
Message 14 of 19
(702 Views)


@Ravens Fan wrote:

 
Let's say that data isn't instantly transferred from one end of the wire to the other.  The CPU could schedule the 2nd subVI to run and complete some or even all of its execution because the error cluster and the control reference are both available at its connector pane, before the CPU has decided to update the numeric indicator with the value that has come out of the 1st subVI.  The execution of the 2nd subVI is not dependent on the fact that the indicator has been updated, really only that the 1st subVI has finished.
 
If data isn't instantly transferred from the source of the wire to its destination,  then there is a possibility of a race condition based on how fast the data flows down the wires.
 


@tst wrote:

Even if you added a 10 second wait in the second subVI before reading the property, there would be nothing to guarantee that the calling VI would not wait 12 seconds before updating the indicator. As such, you can't expect to see race conditions by running the code



This is what I'm worried about. I guess I'll have to make sure it can't happen.

Could it also depend on the the data type? In priniple the Numeric could be replaced with a large complicated array of clusters. Does this take longer to update than the 'simple' numeric.

And on a related note is it possible to read a value while it is being updated, ie starting to read a large array, before new values have finished being put into it? - I hope that the answer to that is NO Smiley Happy, and that the array gets 'locked' while being updated.
0 Kudos
Message 15 of 19
(688 Views)


DavidU wrote:

Could it also depend on the the data type?

It probably does, but the point is that your code should be written in such a way that it can't ever happen.

is it possible to read a value while it is being updated, ie starting to read a large array, before new values have finished being put into it?

You can relax. The answer is a definite no. In general, LabVIEW takes care of such things for you, so you should never have to worry about them.

___________________
Try to take over the world!
0 Kudos
Message 16 of 19
(684 Views)


@tst wrote:

 your code should be written in such a way that it can't ever happen.



   Sure. I'm working on that!


@tst wrote:

You can relax.



I will, it is nearly the weekend after all Smiley Very Happy


Thanks for all the replys - makes interesting reading

Dave

0 Kudos
Message 17 of 19
(666 Views)


Ravens Fan wrote:
This is an interesting thread and seems to talk about a different aspect of race conditions from the usual threads where people are posting code that is just competing local variables.

I agree this thread brings up an interesting (and I think less frequently thought of) aspect of the wires.  Of course as Test 1 has to be complete before Test 2 starts.  That means that data is at the "start" of the wire and we are talking about the amount of time it could take to get to the terminal.  It would be interesting to hear a developers opionon on the "speed" of updating terminals etc. 
 
Tst, I agree with you, if the "condition" is possible, it should be avoided.
 

 
SteveA
CLD

-------------------------------------
FPGA/RT/PDA/TP/DSC
-------------------------------------
0 Kudos
Message 18 of 19
(629 Views)


StevenA wrote:
 
I agree this thread brings up an interesting (and I think less frequently thought of) aspect of the wires.

You should note that the race condition is not caused because of the wire, but because of the value property (which we can't see). In that sense, the race condition is just like this piece of code:
 

___________________
Try to take over the world!
0 Kudos
Message 19 of 19
(616 Views)