OK so I just spent a day debugging an app that had an insidieous race condition and thought I'd share a bit.
The system communicates with a DUT using a USB- Serial adaptor with theFTDIser driver installed. what I saw was sub-vi's that each completed fine on there own however when run from the "test" system I saw some timeout errors.
Adding delays had limited effect however breakpoints and property nodes both solved the issue (so of course I suspected I was insane)
So I ran across this rather interesting post. and yes- I used async calls to VISA read and VISA Write. AHhhh async calls do NOT force async behavior only request async behavior! so I looked into latency of the ftdi driver here and here.
with the async calls I managed to race follow-up VISA calls by starting the second function BEFORE the first completed and locked up the interface. The Breakpoints and property nodes FORCED a switch to th UI thread and the async calls completed synchronously.
Replacing the VISA calls with synchronous calls saved my bacon. (at some time penalty)
"Should be" isn't "Is" -Jay
