Race Condition in Metronome.lvclass:Actor.vi Ticker Loop

[Steven Dusing]

My collogues and I have spent a few weeks tracking down a very tricky race condition issue in the Metronome.lvclass:Actor.vi.

When you start the Metronome Actor, it does initialization stuff, which involves creating the notifier reference and triggering an initial notification for an infinite periodic time (1). Also as part of initialization, a "SetPeriodAndZero" message is sent (2) that gets handled by the Message Handler Loop and also triggers a notification (3). These usually happen with enough time in between that the Ticker Loop handles both as independent notifications, just doing redundant things. No worries.

The problem happens when after the initialization handshake, there's another "SetPeriodAndZero" message (4) that gets sent from the "Start Metronome.vi (the thing that spun up the Actor.vi). This time, the SetPeriodAndZero message has the developer's input for "Initial Period (ms)". This message gets handled by the Message Handler Loop again and triggers another notifier (see 3 again).

There is nothing to guarantee that the first "SetPeriodAndZero" message has been fully handled by the Ticker loop. IF the Ticker loop is somewhere between executing the "Get Notifier Status.vi" and the "Waiting on Notifier.vi" (pink region), then it's possible to miss events, since the first "Waiting on Notifier.vi" ignores previous notifications. It doesn't realize that it doesn't actually have the latest notification by the time it goes from the "Get Notifier Status.vi" to the "Waiting on Notifier.vi"

A few extra details:

• Diagnostic logging confirmed that the ticker loop was never executing
• I was able to demonstrate the potential for this race condition using the attached vi tester, where the only difference between the “ticker” loops is artificial waits used to induce the very specific race condition
• We’ve only noted this issue on RT applications, which maybe is due to different CPU resources available.

Proposed Solution:
Change the "Ignore Previous" input to the "Waiting on Notifier.vi" to FALSE.

[James Powell]

Looks like a major failure on my part to set that “ignore previous”. I have no idea what my reasoning was; must have not understood what that option does. Of course for race-condition-free use, that must be false.

Question, what LabVIEW version do you run in? Next version of ML will be in 2019, and I want to know if I should release a bug-fix for an earier version still in LabVIEW 2013.

‌

Thanks, BTW, this race condition would affect non-RT, just with low probability.

[Steven Dusing]

Hi Dr. Powell, thanks for the quick response! Yes, definitely agree with your assessments. Glad you think the recommended solution will work! Our framework is maintained in LV2020 (for getting to use interfaces), so LV2019 is not a problem in and of itself. Is there a specific reason you’re bumping to LV2019 or just for convenience? My one thought on this is that we do build the ML into packed libraries, so I would just hope that you’re not intending on adding any .vim’s to libraries, since LabVIEW isn’t capable of turning .lvlib’s into .lvlibp’s if there’s a .vim in the library.

[James Powell]

I am adding VIMs, but I’m putting them in a separate library, and you can continue to use the original non-VIM API.

[Steven Dusing]

Sounds good, that should be fine! Worst case is ppl’s for the non-vim lib’s all build in copies of the vim .lvlib if the dependencies point that way.