42 replies to this topic

[Aristos Queue]

Someone at work was building a dialog for a load progress bar. If the load process took more than N milliseconds, the panel should display. If the load process finished first, the panel should not open. Here's what I wrote for him. Anyone have any improvements to suggest?

[LATER EDIT] Thanks to mje who posted a fully correct solution with all the comments from this thread. You can find the correct solution here.

[mje]

I'd probably throw in a release primitive in there for good practice, but otherwise all good I'd say.

[Tim_S]

Hmm... My first inclination would be to use an occurrence instead, but that doesn't change the functionality.

Tim

[Daklu]

Anyone have any improvements to suggest?

Uhh... straighten out your error wire? (j/k ) Clever. I can't help but think about ways of generalizing it into a sub vi that can execute an arbitrary process.

Hmm... My first inclination would be to use an occurrence instead, but that doesn't change the functionality. Tim

Hasn't NI deprecated occurrences in favor of notifiers?

[asbo]

Hasn't NI deprecated occurrences in favor of notifiers?

I hadn't heard that, and would actually find it surprising. Though I haven't used them very many times, I go to occurrences first when I need really simple signalling. DAQ uses them too, doesn't it?

Also, rather than the fill-in-the-blank approach, I would have the VI accept a VI reference and use a blocking Run call. It would force you to make all of the potentially-slow code a subVI, but that may not really be a bad thing. On second thought, though, if the potentially-slow code needed any local data (or returned anything), it would take a more work to pull that off.

[drjdpowell]

Also, rather than the fill-in-the-blank approach, I would have the VI accept a VI reference and use a blocking Run call. It would force you to make all of the potentially-slow code a subVI, but that may not really be a bad thing. On second thought, though, if the potentially-slow code needed any local data (or returned anything), it would take a more work to pull that off.

One could make two subVI's, "Open FP after delay" that outputs the notifier, and "Close FP" that inputs the notifier (as well as the error out of the rest of the code). Then it would be easy to add to any VI and be quite clear. Internals of the two VIs would need to be more complex, with an async call of a third subVI with the actual wait on notification, and some method of making sure "Open..." is finished before "Close..." actually closes the front panel.

-- James

[I'd try and write it if the graphics card on my work laptop hadn't up and died two days ago! "Seven working days to fix" ]

[Daklu]

For kicks and grins I whipped up a quick example of a reusable and semi-generic process progress bar using (of course) LVOOP. I wouldn't consider this adequate for a reuse library since it is UI-centric, but it is something I might use as reusable code within an application. Code is in LV2009.

Example Code BD


ProcessProgressBar.DoProcess BD


WaitProcess.ProcessRunner BD

I hadn't heard that, and would actually find it surprising.

FYI... from LV2009 help, Generate Occurrence Function:

Note National Instruments encourages you to use the Notifier Operations functions in place of occurrences for most operations.

Whether or not that means they deprecated occurrences is subject to interpretation I guess.

Attached Files

•  ProcessProgressBar.zip   87.62K   41 downloads

[asbo]

FYI... from LV2009 help, Generate Occurrence Function:

Note National Instruments encourages you to use the Notifier Operations functions in place of occurrences for most operations.

Whether or not that means they deprecated occurrences is subject to interpretation I guess.

Thanks for the source. I'd like to hear more about this, not because I love occurrences so much as I'm curious why the recommendation arose. The wiki article does mention some "unexpected" behavior - maybe that's it.

[mje]

I'd hazard a guess that notifiers aren't recommended due to their behavior being different than the other sync objects. The behavior is a little odd, but once understood they are perfectly usable.

[Aristos Queue]

Let me fix that for you...

> I'd hazard a guess that notifiers occurrences aren't recommended due to their behavior being
> different than the other sync objects. The behavior is a little odd, but once understood they are perfectly usable.


With my amendments, yes, you're correct

It is very hard for most folks I've worked with to understand how and why occurrences work. The Notifier wrapper (it uses occurrences under the hood, as does all sleep/wake behavior of LV) generally makes things clearer.

I'd probably throw in a release primitive in there for good practice, but otherwise all good I'd say.

Yeah, that should be added since he's probably calling this as a subVI repeatedly.

[mje]

Hah, yes, of course I meant occurrences. Doh.

[Tim_S]

It is very hard for most folks I've worked with to understand how and why occurrences work. The Notifier wrapper (it uses occurrences under the hood, as does all sleep/wake behavior of LV) generally makes things clearer.

The amusing part of that is I'm the opposite... I understand occurrences better than notifiers. Though, in full disclosure, I can't ever recall using notifiers.

Tim

[rolfk]

Occurrences are the underlaying functionality of all LabVIEW asynchronous operations. However they have a few limitations in itself.

1) They don't allow for any data to be associated to them
2) They have somewhat confusing semantics
3) You can get a triggered occurrence from set occurrence invocations that happened before the wait occurrence was called even when ignore previous is true. This can be worked around easily by checking for the actual event in some other ways and reentering a wait if the event wasn't really true, but one needs to be aware of it.

[Aristos Queue]

I had a conversation with our chief architect whose been working on LV since version 0.1 and who created the occurrences long long ago. Here is THE correct way to use occurrences:

First build a system which polls busily for whatever it is the occurrence will signal. You need to be able to determine the state of things without an occurrence. This creates a correct, but inefficient busy waiting implementation. Once that works, add an occurrence to alleviate the inefficient waiting. Do not remove the actual polling. In other words, use the occurrence only to indicate that "it is probably a good time to check on that thing...".

[Later Edit] I added a much better example of the usage of occurrences a few days later in this thread. Read it here.

In other words, start with this:

and then go to this:


As I understand it, occurrences don't have thread safety on their state because they are the building blocks by which thread safety for state in higher level APIs is built.

[ShaunR]

I had a conversation with our chief architect whose been working on LV since version 0.1 and who created the occurrences long long ago. Here is THE correct way to use occurrences:

First build a system which polls busily for whatever it is the occurrence will signal. You need to be able to determine the state of things without an occurrence. This creates a correct, but inefficient busy waiting implementation. Once that works, add an occurrence to alleviate the inefficient waiting. Do not remove the actual polling. In other words, use the occurrence only to indicate that "it is probably a good time to check on that thing...".

In other words, start with this:

and then go to this:


As I understand it, occurrences don't have thread safety on their state because they are the building blocks by which thread safety for state in higher level APIs is built.

That won't work.

[Daklu]

That won't work.

Care to elaborate? (I've never used occurences and I'm finding it a bit confusing.)

[Darin]

Care to elaborate? (I've never used occurences and I'm finding it a bit confusing.)

Consider when the local variable is read and comparison is made.

[ShaunR]

Care to elaborate? (I've never used occurences and I'm finding it a bit confusing.)

Because the local variable will be evaluated well before the first loop reaches the large number and will present a FALSE to the stop terminal. Everything (in the second loop) then waits for the occurance. Once Loop 1 actually fires; loop 2 then proceeds with the FALSE, goes around again and then waits, once more, on the occurance-which never arrives since the first loop has already terminated.

This is why no-one uses them. Its too easy to get race conditions that hang your app because they don't have a time-out.

It will work correctly IF you put the occurance and the local into a sequence structure that guarantees the local is read AFTER the occurance (another reason no-one uses them since they don't have error terminals and forces you to use those pesky sequence structures.)

Edited by ShaunR, 08 October 2011 - 01:45 AM.

[mje]

Occurrences do have a timeout.

The main reason occurrences behave differently than the other sync objects is because occurrence refnums are static. The refnum is created when the VI that contains the Generate Occurence function is loaded, not when it is executed. That means that a VI which is reused, say in a loop, the Generate primitive will return the same occurrence on each invocation. This is often counter-intuitive to those that don't understand the mechanics of how occurrences are created and can lead to some serious bugs due to previous values being in the occurrence.

The fact that they're created on load is also the reason there is no need for a destroy primitive. Memory leaks don't happen because repeated calls to Generate Occurrence in the same VI always return a reference to the same instance.

The behavior is very useful if the primitive behaviors are understood though. They just work completely different from all the other synchronization primitives.

[ShaunR]

Occurrences do have a timeout.

I stand correct4ed (when did they add that then?)

The main reason occurrences behave differently than the other sync objects is because occurrence refnums are static. The refnum is created when the VI that contains the Generate Occurence function is loaded, not when it is executed. That means that a VI which is reused, say in a loop, the Generate primitive will return the same occurrence on each invocation. This is often counter-intuitive to those that don't understand the mechanics of how occurrences are created and can lead to some serious bugs due to previous values being in the occurrence.

IMHO this is how the other primitives should behave (and that includes diagram, project and control refs). I've lost count of the number of times I have had to correct others' code because the refs aren't closed. It is these primitives that are counter and intuitive rather than the occurrence. Oh for the days when Labview meant you didn't have to worry about memory leaks.

The fact that they're created on load is also the reason there is no need for a destroy primitive. Memory leaks don't happen because repeated calls to Generate Occurrence in the same VI always return a reference to the same instance.

The behavior is very useful if the primitive behaviors are understood though. They just work completely different from all the other synchronization primitives.

Seems to me that they work similarly to a notifier (since they have a timeout) without the pit-fall of memory leaks.

Edited by ShaunR, 08 October 2011 - 03:30 AM.