Race Condition.

[Ray.R]

Even with multicore processors... It's like Ben says.. LV will resolve all values that do NOT have any dependencies on previous code FIRST. THEN it does everything else.  So if it's not 0%, it will be very close to 0%.

[shoneill]

Well I for one am not one to believe what the profiler in LabVIEW shows me.  Runtime performance is often quite different.  I have experience several cases where race conditions only appear when run at full speed......

Either way, I believe LV may QUEUE all of the operations without dependencies first, but if something delays an operation (like a thread switch), then nobody knows any more when anything is going to happen.

I do agree that the chance is very close to 0%, but I wouldn't be willing on it being EQUAL to 0%.

Shane.

[altenbach]

---

JoeLabView wrote:

Even with multicore processors... It's like Ben says.. LV will resolve all values that do NOT have any dependencies on previous code FIRST. THEN it does everything else.  So if it's not 0%, it will be very close to 0%.

---

However, a dependency could occur at any moment in the future after some editing. For example if the programmer hears somewhere that it is typically a good idea to wire error clusters (these things happen! :)). If he now wires the error input of the property node, things might change again because now we have a data dependency on the property node. I would call anything that can change the result after some seemingly unlrelated code changes a race condition.

No matter what, it is a potential race condition. We also don't know if the current behavior will hold for all future versions of LabVIEW. Suddenly, a genious at NI will make an optimization to the compiler where things might execute differently. 😮 Imagine if there were another property node (e.g. visible, etc) for the boolean in the same structure, the compiler could possibly combine them into a single syncronous call to save on the overhead of property nodes and thus postpone the read. Just wildely speculating here... 😉

Unless there is clear documentation of this ordering or a strict internal NI policy that all nodes without dependency MUST be resolved first (or else!), I would not try to predict the outcome. 😄

There is also the fact that race condions often disappear when the VI is run in highlighting mode. I am not sure if we can fully conclude from the execution order in highlight mode what the execution order will be without highlighing or after disabling debugging. Is there really a clear word on this? Just curious, maybe there is. 🙂

[Ray.R]

Wow... that's a lot of discussion over a race condition LOL!! 😄

I agree with both of you.  I too have seen different behavior at full speed as Shoneil pointed out.

As for code changes.  Well.. code is often quite dynamic.  Especially when learning the language. So yes, a simple wire to the error in terminal of the property node will absolutely change the behavior.  There's no telling what that will be...  But as the code is shown, we all agree that it is near 0 probablility that the boolean will be updated before the selector is read. 

For some strange reason, some people think that location on the block diagram influences what runs first..  😄  Let's not get into that one.. 😉

[altenbach]

---

JoeLabView wrote:

For some strange reason, some people think that location on the block diagram influences what runs first..  😄  Let's not get into that one.. 😉

---

Well, we've just seen one of those. Look at the middle sequence frame. It is pretty clear what the intention of the programmer was. 😄

(from http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=317545#M317545 )

[K C]

---

JoeLabView wrote:

For some strange reason, some people think that location on the block diagram influences what runs first..    Let's not get into that one..

---

No only the location is important but also the comment should do some of the work

(this piece comes from a driver I downloaded)

Message Edited by K C on 04-22-2008 08:38 AM

[shoneill]

KC,

I did NOT know that.  I really should comment my code some more then......

Seems the LV compiler is really smart.....

Shane

[Ray.R]

I see code like Altenbach's example very often.  It just clutters the BD.

Now...  comments that execute, that's a first!  LOL!!  😄  And execute with respect to where they are located on the BD!  Now that's a powerful language! 

LOL!! 😄

[JeffOverton]

that's not so weird Ray.  If you forget a couple characters in C or VB your comments execute inline

[K C]

Yeah, it's not easy to keep up with all those new LV features