No difference between using a local variable and a notifier in timed parallel loops?

[Hosehead]

The example code "Pass Data With Notifiers.vi" that came with LV 7.1 illustrates using notifiers with parallel loops.  Just looking at two of the loops, the one that generates the sine wave and the one for "User 1", you can change the timing of the two loops and you can change the condition of the "Ignore Previous" status on the "Wait on Notification".  I have a special case of this to consider, where I'm wondering if there's any reason not to use a local variable instead of the notifier:

Set the delay on the generator portion (which contains the Send Notification) to something very short, say 5 ms.  Set the delay on the User 1 (which contains the Wait on Notification) to something relatively longer, say 200 ms.  Set the Wait on Notification to False.  Now you have a situation where the User 1 loop action is contingent only upon the loop delay time, since each time the loop timer runs the loop there will always be a value in the notifier.  In this case it seems to behave just like the case where you update a local variable in the fast loop and read it in the slow one.

Is my understanding correct?  Would there be a performance difference between the two methods?  What do you prefer in this situation and why?

Thanks,
Hosehead

[tbd]

Hi H.,

I think your idea is to write to a Global Variable in the data-producer VI, and read it in the data-consumer VI(?)

One reason this might be less efficient than using Notifiers is if you want to graph every new value in the "consumer" - or make sure the value read in the consumer has changed at least once since the last loop.

> since each time the [consumer] loop timer runs the loop there will always be a value in the notifier...

> Would there be a performance difference between the two methods? 

If you don't use the Notification "event" to synchronize the producer and consumer, then to be sure the consumer gets a new vaue, you've made the producer loop faster - every 5 ms - a waste of cpu-cycles.  More often the situation is reversed, that is, there's a consumer that needs to see every single new value, and (without events) the consumer must loop faster than the producer (to catch every new value) - this is called polling and it wastes cpu-cycles.

Just about anytime one's tempted to make a loop execute "fast" to check on some value (or to make sure there's a fresh value,) there's an opportunity to improve performance through synchronization with events (including notifiers, queues, occurrances, semaphores, and rendezvous')

tbd

Message Edited by tbd on 07-09-2006 03:51 AM

[Hosehead]

tbd - In my case I'd be looking at having the producer act as the data acquisition and logging to file loop (hence the high speed) and the consumer as a calculation loop (e.g. PID calculation every 200 ms on the current value).  So I think what you're saying is in this case there's no inherent performance difference in using a local (actually you said global) variable from a notifier.  Do I understand correctly? 

Thanks,
Hosehead

[Justin D]

Hosehead,

I think for your application the best thing to use would be a local variable.  Notifiers are really only usefull if the consumer will have to wait for data at any point.  If data is always going to be available when the consumer needs it then there's no need for the extra complexity of a notifier.

Hope this helps,
Justin D.
Applications Engineering
National Instruments

[Hosehead]

Justin,

That's what I was thinking.  Just wanted to confirm that's actually the case and notifier didn't have some other (performance) advantage I don't know about.

Thanks,

Hosehead

[tbd]

Hi H.,

      I must have misunderstand your original post, I though you were considering passing information from one VI to another - in which case you'd have to use a Global (not a Local).  If I got it right after all, you may be interested in this link that talks about a "performance-hit" from writing to a Global in a "really tight loop".

Cheers.