Race conditions with UI thread

[Yamaeda]

---

@Florian.Ludwig wrote:

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

---

I guess you can add a FP.state-property to check/wait until it defacto has opened, or simply add a 100ms wait.

/Y

[Florian.Ludwig]

Thanks,

that FP.state check will probably solve this specific issue. I will probably go with that or Norberts suggestion of putting the invoke node in the mani vi.

It wouldn't have solved the issue with the x-y graph though.

A general solution for this kind of problem would be nice.

The more I think about it the more I feel that the way this is implemented by NI violates dataflow.

Best regards

Florian

[Florian.Ludwig]

Update:

I found a way to reliably reproduce the error in my original app. I just close the fp of the sub-vi programmatically downstream.

Mashing the Button to open it fast enough will produce the error quickly.

So I could finally test the following.

Checking for FP.status in a while loop inside the sub-vi until ok: doesn't help 

Opening the sub-vi's FP in caller: doesn't help

Aligning LabVIEW.exe to one core only: doesn't seem to change the number of clicks needed to produce the error.

Will try to condense this into an example now.

Best regards

Florian

[Florian.Ludwig]

Update:

---

Florian.Ludwig wrote:

I found a way to reliably reproduce the error in my original app.

---

No I didn't.

I made a mistake in my attempt to reproduce the issue - sorry.

I'm still working on it.

Best regards

Florian