Race conditions with UI thread

[Florian.Ludwig]

Hi community,

the update to LabVIEW 2014 has caused sveral of my vis to act up - vis that I had coded with race conditions with the UI thread that I was not aware of.

Maybe they didn't exist previously, maybe I was just ignorant.

Here is a where I first noticed something was wrong. It has a workaround inside:

http://forums.ni.com/t5/LabVIEW/How-to-make-sure-plots-in-xy-graph-are-present/td-p/3033109

Thanks again Norbert for your help with that.

Now problems are showing up in other places too and it might be the tip of an iceberg. I'm a little afraid right now. It's not just xy graphs. The latest example:

I have a sub-vi whose frontpanel I open with an invoke node inside that sub-vi. Afterwards, in the caller I register for events of frontpanel objects of the sub-vi. This fails now - apparently the fp of the sub-vi isn't open yet although the sub-vi has finished executing (yes, I use dataflow to ensure register for event is done only after the sub-vi has finished). This has a striking resemblance to my issue in the previous thread. It seems that vis can now be "finished" executing while stuff that was supposed to happen inside the sub-vi is still executing in the UI thread.

I had not expected this.

Is this intended behaviour?

Is this new to LabVIEW 2014?

Can someone please shed some light on this behavior change (if indeed it is one)?

Can someone please advise me on a general solution/workaround for the host of problems this is causing me?

Best regards

Florian

[Norbert_B]

Florian,

you can limit LV to run on a single core in the Windows Task Manager. For this, select the LabVIEW.exe process and in the context menu click Set Affinity.... .

If the amount of issues is reduced, the race conditions are a good guess for the reason.

Are you using the same PC as you used for previous versions during development? If not, how does the "old" system behave with 2014?

Regarding your latest example: Moving the invoke node "Show FP" to the caller should be an easy solution for the issue.

Norbert

[Yamaeda]

I doubt it's new to 2014 and as to intended, well it compiles and runs as fast as possible, which i suppose is your intention.

Without seeing code it's hard to say anything more than general tips, but it does sound like a Race Condition. When upgrading to 2014 it'll recompile the VI , possibly reordering the variable reads, which seems to have happened in this case.

/Y

[Florian.Ludwig]

Norbert,

thanks for answering

Regarding the "run on single core" proposition:

The programm will be distributed as an executable. I guess changing the behaviour of my LabVIEW.exe will not carry over to the targets.

It's on the same PC. Only change I am aware of is the update to 2014. The same goes for a second PC I could test with.

Thanks for the suggestion on moving the invoke node to the caller, that should work. I guess I'll have to chip away the iceberg chunk by chunk.

Yamaeda,

my intention is for sub-vis to finish executing before other code starts executing downstream. 😉

I realise that LabVIEW isn't developed to cater to my expectations - I had just thought that my expectations where pretty mainstream here.

I don't think it's variable reads. I'll try to work up an example to post.

Best regards

Florian

[Norbert_B]

Florian,

restricting the execution to a single core is no solution. It never will be. I just want you to get a feeling how parallel execution and/or "arbitrary order of execution of threads" is affecting your issue(s).

Norbert

[Florian.Ludwig]

Norbert,

I'm currently unable to reproduce the issue in my code regardless of cpu core affinity (you gotta hate random errors).

I have attached an example that shows a simplified version of the code that has previously produced the error.

This example might be flawed since it hasn't produced the error yet.

The issue would show when the button "open window" is pressed, if it did at all.

Also there is stuff in there that I just implemented in an attempt to keep the UI thread busy.

For the core of the issue please disregard the bottom while loop in caller.vi

I'll keep trying.

Best regards

Florian

[Yamaeda]

I did a small change to the sub-vi removing a race-chance, though i cannot understand what the meaning of it is.

Also, why are you setting the captions and not the values?

/Y

[Yamaeda]

You can/should also remove the two references of the controls[] before setting all.

/Y

[Florian.Ludwig]

Yamaeda,

thanks for reviewing my example.

I made it up to reproduce the error I described earlier - the example does nothing useful.

I was setting captions in the sub-vi just because something similar happens in my actual programm when I open its frontpanel. Captions are inserted based on the GUI language selected by the user.

Removing the two references you mentioned would be the way to go if this was code that I'd plan to put to use. I was just trying to emulate my issue in a quick and dirty fashion.

Good catch on the possible race inside the sub-vi. I was so intent on digging up the race of the sub-vi's UI thread calls with the caller's UI thread calls that I overlooked that in my quick and dirty example.

Best regards

Florian

[Florian.Ludwig]

Hi all,

I'm having a hard time reproducing the error as it happens only very sporadically. I could only do it once since yesterday. But then it kept throwing the error until I stopped the programm.

Since then I have restarted the program numerous times in an effort to reproduce the error to no avail. I can't really test if any measures make it show more or less that way.

The principal error pattern remains the same whenever the error shows:

The instruction inside a sub-vi (in this case an invoke node to display its frontpanel) is not finished but the sub-vi "claims" it is by delivering data to its outputs, therefore triggering other code downstream to execute. If that code is expecting finished execution of the sub-vi there will be trouble.

Is there a way to make sure the code inside a sub-vi is completely executed (even the parts running in the UI thread) before it signals "I'm done" to the rest of the code?

If there was a simple switch, or even a workaound that needs to be placed in the sub-vi in question that would help me tremendously.

Best regards

Florian