DVR, in-place element and locking (+freeze)

[mike5]

Hi all,

IIUC (from some other threads on this forum) if in-place element fails to obtain a lock, it gives an error and provides you with a default value of whatever the reference points to, and continues.

But that's not what I'm seeing.

If an in-place element on DVR is used from two processes, then one of the processes simply "freezes" (enters an endless wait maybe). Also, since my DVR always point to a cluster, I'm using in-place element inside an in-place element (outer one for DVR, inner one for bundle). I'm mentioning this just in case that the freeze-up doesn't occur from accessing the DVR, but the bundle...

Can anyone shed some light on how to process the same bundle from two different processes? Currently I have resorted to using semaphores to avoid the problem (and it seems to work), but is this the right way (performance-wise), or is there a better way?

Thanks, Miha

[mje]

...if in-place element fails to obtain a lock, it gives an error and provides you with a default value of whatever the reference points to, and continues.

This I believe is true, but an IPE (in-place structure) will only fail to obtain the lock if it's supplied with an invalid reference: the DVR has been deleted, a Not A Refnum (or similar) was supplied, etc.

An IPE will only block (wait, or "freeze") if another IPE is currently working on the reference (this is not an error). The IPE will signal (resume execution) when the reference becomes available again. A semaphore is traditionally how you protect resources like this, but there's a semaphore inherently built into the DVR as only one IPE can access it at a time. Under most situations you shouldn't need to protect the DVR with an explicit semaphore.

Edited March 30, 2010 by mje

[mike5]

This I believe is true, but an IPE (in-place structure) will only fail to obtain the lock if it's supplied with an invalid reference: the DVR has been deleted, a Not A Refnum (or similar) was supplied, etc.

An IPE will only block (wait, or "freeze") if another IPE is currently working on the reference (this is not an error). The IPE will signal (resume execution) when the reference becomes available again. A semaphore is traditionally how you protect resources like this, but there's a semaphore inherently built into the DVR as only one IPE can access it at a time. Under most situations you shouldn't need to protect the DVR with an explicit semaphore.

Thanks for your answer!

Is the implicit semaphore implemented for all types IPE structures, or just the DVR related ones? If it is DVR only, don't other instances need it?

Also, do you happen to know how is the semaphore locking resources-wise? Greedy? Slow? Alright? I'm hesitant to remove it now that I have it working, but I might sometime in the future, if all it does is to re-implement something that's already there.

Br, Miha

[Yair]

I suggest you upload your code if you can't solve this.

In general, only DVRs do the lock and in fact, that's their defining behavior - they allow you to share a single block of data by locking it when it is accessed. If your code gets stuck, I would guess that you ran into a deadlock - both places are stuck waiting on each other. As mentioned, under normal circumstances this doesn't happen. If the DVR is the only lock you have in the code, make sure the reference wire does not cross the border of the IPE structure into it.

[Aristos Queue]

Is the implicit semaphore implemented for all types IPE structures, or just the DVR related ones? If it is DVR only, don't other instances need it?

Only the DVR needs it. All the other IPE border nodes are accessing data on the local wire -- there's nothing shared with other processes that needs locking.

[mike5]

I suggest you upload your code if you can't solve this.

In general, only DVRs do the lock and in fact, that's their defining behavior - they allow you to share a single block of data by locking it when it is accessed. If your code gets stuck, I would guess that you ran into a deadlock - both places are stuck waiting on each other. As mentioned, under normal circumstances this doesn't happen. If the DVR is the only lock you have in the code, make sure the reference wire does not cross the border of the IPE structure into it.

Yes, I have identified a deadlock as well. Unfortunately it was wrapped into multiple layers of VIs, so it wasn't obvious at first and required two days of tracing to discover.

And on that note, am I the only one who finds debugging/tracing in LabView more useless than useful - with each VI opening two windows until you're completely lost. Any plans on somehow making the experience better?

Thanks for all your help. Miha

[Aristos Queue]

And on that note, am I the only one who finds debugging/tracing in LabView more useless than useful - with each VI opening two windows until you're completely lost. Any plans on somehow making the experience better?

It's been that way for 25+ years. I doubt that anything substantially altering that situation is likely anytime soon. I actually find the experience fairly straightforward when I compare it to 4000 lines in a .cpp file that I'm scrolling up and down through. Even in C# where files tend to be on the order of 100 lines, the windowing situation gets pretty bad. At least with LV you can observe from the probes behavior at deep levels of the program instead of having to actually be watching those levels real time to see watch window results.

Yes, I have identified a deadlock as well. Unfortunately it was wrapped into multiple layers of VIs, so it wasn't obvious at first and required two days of tracing to discover.

That, by the way, is the number one reason to not use data value references. Yes, they're bright and shiny and new in LV 2009 and a bijillion users have thanked us for adding them to the language, but I continue to argue that the vast majority of the time the same work can be achieved with dataflow and doing so would avoid the deadlocks and race conditions that too often crop up. Yes, there are rare situations where you really do need a DVR, but its way less common than most people seem to believe. Perhaps having spent two days searching for the deadlock, you'll now spend a couple days thinking about whether it is possible to architect your code without any DVRs to avoid this in the future. I'm not saying it is necessarily possible in your case, but I believe it is worth thinking about.

[mike5]

It's been that way for 25+ years. I doubt that anything substantially altering that situation is likely anytime soon. I actually find the experience fairly straightforward when I compare it to 4000 lines in a .cpp file that I'm scrolling up and down through. Even in C# where files tend to be on the order of 100 lines, the windowing situation gets pretty bad. At least with LV you can observe from the probes behavior at deep levels of the program instead of having to actually be watching those levels real time to see watch window results.

I'm pretty new to this, but I think having a way of saying "Don't open front panels for SubVIs during tracing" would help a lot...

That, by the way, is the number one reason to not use data value references. Yes, they're bright and shiny and new in LV 2009 and a bijillion users have thanked us for adding them to the language, but I continue to argue that the vast majority of the time the same work can be achieved with dataflow and doing so would avoid the deadlocks and race conditions that too often crop up. Yes, there are rare situations where you really do need a DVR, but its way less common than most people seem to believe. Perhaps having spent two days searching for the deadlock, you'll now spend a couple days thinking about whether it is possible to architect your code without any DVRs to avoid this in the future. I'm not saying it is necessarily possible in your case, but I believe it is worth thinking about.

Well, we have a collection of "active objects" communicating with each other, and they all have some parallel loops as well. IIUC each "process" and parallel loop gets its own copy of the attributes, which doesn't help much. Or am I wrong?

Miha

[mje]

That, by the way, is the number one reason to not use data value references. Yes, they're bright and shiny and new in LV 2009 and a bijillion users have thanked us for adding them to the language, but I continue to argue that the vast majority of the time the same work can be achieved with dataflow and doing so would avoid the deadlocks and race conditions that too often crop up. Yes, there are rare situations where you really do need a DVR, but its way less common than most people seem to believe.

I'll agree. I'm glad DVRs are there, but have yet to actually implement anything with them. Over a decade of LV programming has taught me interesting ways to keep my logic mostly value based. However, I acknowledge that DVRs have their place and I think LV is a better language for having them.

I think a lot my lack of use of DVRs (or the fact that nearly a year later I'm just starting to play with them), is that there is already a lot of reference types floating around that let me do most of what I need to do. The advanced synchronization features I use daily (queues, notifiers, events, and even VI server) can suffer from the same deadlock problems if implemented poorly, yet have become part of the most fundamental programming architectures in LabVIEW.

As for the windowing mess...all I really want is a distinction between panels, diagrams, controls, and other window types in my task bar. Give me a different icon depending on what window type it is...even better yet, give me the icon of my VI/Control in the task bar.

That, and make project explorer windows floating (always on top). Please, for the love of sanity.