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

Question

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

Answer 1

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
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)