case statement evaluation order

[pchaopricha]

Hello,

   This is a pretty basic question, but I couldn't find a clear answer to this.  We have a following code:

Several people were concerned that there's a race condition between setting the RTS and DTR state in the diagram.  When I run the code debugging, the RTS state seems to be set first since the case statement doesn't get evaluated until the RTS state was done setting.  A guy argued that the code debugging doesn't accurately represent the execution order of the code and therefore cannot be used to determine whether or not this is a race condition.   

I actually hooked the hardware up to a logic analyzer and ran this 1,000 cycles and every single cycle seems to have RTS state set firsts, which seems consistent with what the debugger is doing.

My question is: can I trust the debugger code stepping?   Additionally, does LabView evaluate the case statement at the same time as the items outside the case statement?

Any clarification would be greatly appreciated.

Thank You,

Patrick

[billko]

---

@pchaopricha wrote:

Hello,

   This is a pretty basic question, but I couldn't find a clear answer to this.  We have a following code:

Several people were concerned that there's a race condition between setting the RTS and DTR state in the diagram.  When I run the code debugging, the RTS state seems to be set first since the case statement doesn't get evaluated until the RTS state was done setting.  A guy argued that the code debugging doesn't accurately represent the execution order of the code and therefore cannot be used to determine whether or not this is a race condition.   

I actually hooked the hardware up to a logic analyzer and ran this 1,000 cycles and every single cycle seems to have RTS state set firsts, which seems consistent with what the debugger is doing.

My question is: can I trust the debugger code stepping?   Additionally, does LabView evaluate the case statement at the same time as the items outside the case statement?

Any clarification would be greatly appreciated.

Thank You,

Patrick

---

The following is a pretty basic response because your picture link is broken.  Can you trust the timing of stepping mode in a text-based program?  Of course not, because then YOU are controlling the timing.

So you hooked up this thing and it ran the same 1000 times.  All that means is that the correct thing won the race 1000 times.  What happens if you run it on a machine with a different architecture or speed?  What happens if something installed on your computer - including Windows - decides to check for updates when this thing is running?

If several people say you have a "race condition," why not investigate WHY this may be the case instead of trying to justify your own code to people more experienced than you?  You actually ARE trying to investigate this.  Sorry.

Here's a link that shows you datflow programming basics.  If you can understand this, it should answer your other questions as well.

[pchaopricha]

Sorry about the broken link.  I placed image in a different location.

http://imgur.com/N2IO7oD

Yes, I'm trying to investigate this because I did run this at different speeds and time interval and the results are the same.  I also ran it on 3 different computers which are similar in architectur (Intel Core i5) but that's all we have for computers around here.  So far I couldn't produce the race condition yet.   It's possible that I'm lucky 30,000 times in a row but maybe there's something to it more than just luck. I did look at the data flow basic from the link that you provide and it didn't explicitly state whether the case statement would get execute before or after item outside of the case statement.   I assume that LabView evaluate the outer most layer first and then go in.

I want to clarify "debugging".  I turned on the Light Bulb debug which just slows down the processing to show me the data flow in the code layout.  When I did this, RTS State always get set first.   I didn't manually step through the code so I didn't control the flow of the code.

We already found a way to gaurantee the data flow by using the wiring in order of the steps we want to happen.  However, it doesn't clear up my question regarding how the order of execution is done via LabView and how do you know what runs first if the debugger itself isn't correct.   Normally when I use the LightBulb tool, it shows the order of execution and so far I think the sequence it's doing things seem to be correct.  If something is running in parallel, I would see the data dots flow to both places at the same time.  

I would believe that the code I posted is a race condition if the debugger shows that the data flow goes to both the RTS State and DTR State at the same time.  However, so far it finishes the set RTS outside the case statement first then goes in to the case statement to set the DTR state.

Thanks,

Patrick

[RavensFan]

We can't access that either.  Don't use 3rd party websites.  They are blocked by many people's corporate web filters.

Attach your image to your message using the Attachments section right below the message window.  It will attach the file to your message and then we'll be able to open it up just fine.

[pchaopricha]

OK, I attached it here now.  Thanks.

[pchaopricha]

Not sure why the attachment doesn't go through.  Maybe it needs jpg.  Hopefully this works.

[CoastalMaineBird]

Here is your picture.

[0utlaw · Accepted solution]

Hello Patrick,

Your colleague is correct- the image you posted shows a potential race condition.  Keep in mind that Execution Highlighting single-threads the execution of your block diagram and only one thing can happen at a time, so it doesn't accurately represent the execution of parallel processes.

The good news is that the fix is simple- you just need to introduce a flow dependency that forces execution order.  Branching the instrument and/or error wires after setting the RTS state rather than before seems like it would do what you want.

Regards,

[CoastalMaineBird]

You definitely have a potential race condition.

There is no guarantee which of those property nodes will execute first.

the fact that it works right 1000 times in a row is no guarantee that it will work the next time or on a different computer or a different LabVIEW version.

You need to rethink your logic.

If ________

    Set ASSERTED

else if _______

    Set UNASSERTED

else

    Leave it alone (maybe).

[RavensFan]

That's better.  I don't know what file format you tried to attach in the previous message.  Bitmaps are blocked due to there overwhelming size.  Jpeg's and PNG are acceptable.

You do have a race condtion.  Either RTS or DTR state will execute first since you wired them to execute in parallel.  Using Highlight Execution won't tell you anything about execution order since LabVIEW intentionally slows everything down to show you each piece of data flowing.  If something works one way in normal execution, but works wrong, or sometimes "better" in highlight execution, then that is a sure sign of a race condition.

If you want one to execute before the other, then wire the Error wire from one to the other to guarantee it happens that way.  Learning about dataflow is Basic LabVIEW 101.