RT timed loops and notifiers

[xl600]

I have a bunch of timed loops which read notifiers.  Primarily these are for simply stopping the timed loops.  None of the timed loops write to notifiers.

Does a notifier read (0ms timeout) affect the determinism of a timed loop?  If so, is there a better option for stopping multiple parallel timed loops?  An RT FIFO doesn't lend itself to a 1:many synchronization.  An FGV certainly doesn't seem appropriate.

Thanks,

XL600

[nathand]

I don't know the answer to whether a notifier will affect determinism, and of course it also depends on how much jitter you can tolerate. If there is any effect it's probably minimal.

An FGV may actually be reasonable, because you have the "Skip if busy" option to prevent a busy VI from affecting determinism.

[xl600]

The skip if busy option for an FGV returns default values.  That doesn't tell me if it skipped or if it just happened to have the default values as actual valid values.  For a stop condition, this may be an issue (I would have to think carefully about the effect on my loops potentially running again once or twice after the stop was issued).

[crossrulz]

Have you concidered the simple (and super fast) Global Variable?  Assuming you initialize it to FALSE at initialization before anything else starts running and only write a TRUE to it otherwise, you do not have race conditions.

[xl600]

I've tried to avoid globals, but in this case it seems like it would be nearly the perfect tool.  A single writer, many (many) readers.  Only gets set to true once and then everything comes to a halt.  How many copies of the global get created though (One for each placement of the global and clone)?

I use FGVs in a few other places for state variables and I've been getting worried about the number of readers there as well potentially causing fairly long blocks to occur.  A bit off the topic though, the question at hand is to understand the effect of notifier reads within RT loops.

[CMal]

I typically use boolean notifiers with 0 timout to stop multiple loops, and I've never noticed an impact on determinism with timed loops.  I like them better than FGVs or global variables because it allows for the possibility to stop some but not all loops by giving different notifier refnums to different loops.

On a side note, I've used timed loops less and less as I've created more RT applications over the years.  They add some extra performance overhead, and they don't do much other than run your loop at a specific rate, which can be done just as effectively with a while loop and Wait until Next Multiple.  Unless I need to assign loop priority or processor affinity, I usually try to avoid them.

[xl600]

That's pretty much how I've been doing things.  The main use I have for timed loops for is for software sampling routines that need determinism or because I'm being a bit lazy and want to take advantage of the various features (Like late finish detection) of timed loops without having to code them myself.

[natasftw]

If you need determinsm, creating more timed loops is counterproductive.  The loop with the highest priority will run first and consume the core.  This is true even as you build up to multiple cores.  The lesser priority loops lose their determinstic nature as they can be preempted by the higher priority loop. 

If they're all the same priority, they're going to share the cycle.  This idea is inherenently non-deterministic. While sharing may be caring, it doesn't ensure a loop finishes within the jitter bounds.

You're adding overhead, which means processing time in each cycle.  This means you're pushing yourself further towards the jitter bounds, not increasing determinism.

You'd be better served by converting less important tasks to while loops and increasing the amount of processing time you have to work in each period.

[xl600]

That's good advice indeed.  Only a few of my timed loops need to be low jitter so those are the higher priority loops.  If I bump into any jitter threshold (Which I will measure at some point once more of the code is complete), I plan to merge operations and move less critical things out of the timed structures.  So far, I'm sure I'm nowhere near any threshold just processing software timed analog samples and network traffic.  When I add my video data, that's when things will get interesting.