Timeout on IPE for DVR?

[OlivierL]

I heard about this problem before and personally ran into it quite a few times: DVR access don't have a timeout option which means that if the code in DVR A uses DVR B and that "by mistake", DVR B attempts to use DVR A, your code just hangs forever.  I am quite surprised to see that I cannot find a post about this issue on LAVA. I could find one idea on the idea exchange but it is not very popular:  http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Timeout-for-In-Place-Element-Structure-with-DVR-nodes/idc-p/3181029#M31895

 

Are we a very small minority to use this DVR and IPE with objects and sometimes run into circular references during development?  Are others actually implementing their own Semaphores manually before the IPE structure?  Is there a clean and simple solution that I am not aware of to circumvent this problem?

 

I am curious to know how people are fairing with this issue and if more people are interested, to make the suggestion from Chris more popular.

[infinitenothing]

I don't run into this issue much but back before we had DVRs, many people were using single element queues for the same purpose.

[ak_nz]

The best practices we follow is to limit activities in DVRs to setting or retrieving data. We don't use DVRs as a "lock" mechanism to limit access to a resource. If we need such behavior we implement any other locking functionality that has time-out capability such as semaphores, SEQs or the ESF.

 

This has allowed us to avoid a host of issues, such as deadlocks in dynamic dispatch methods between DVR'd classes in a hierarchy.

Edited August 20, 2015 by ak_nz

[OlivierL]

I don't run into this issue much but back before we had DVRs, many people were using single element queues for the same purpose.

Yes, and those are great because there is a time out feature that allows the application to continue, recover and provide useful information for fixing the problem.  Do you also mean storing the object itself in a SEQ instead of sharing a DVR?  Does that mean that all of your class methods must be surrounded by the Dequeue/Enqueue?

 

The best practices we follow is to limit activities in DVRs to setting or retrieving data. We don't use DVRs as a "lock" mechanism to limit access to a resource. If we need such behavior we implement any other locking functionality that has time-out capability such as semaphores, SEQs or the ESF.

 

This has allowed us to avoid a host of issues, such as deadlocks in dynamic dispatch methods between DVR'd classes in a hierarchy.

I don't think that the idea is to use DVR to lock a resource.   For many of our objects, we call methods on them using DVR (ByRef).  Every now and then, we realize that two objects end up with a circular dependency that was not expected and we experience a deadlock that just cannot be recovered from. 

 

I appreciate that limiting the use of DVRs to basic accessors reduces the risk but it also restricts us from using more useful methods that are properly protected inside the object.  Drawing the line can be challenging between reducing the risk and protecting class methods.  Is there any VI Analyzer functions that allow for automatic check for an IPE inside an IPE where both have a DVR?  It may not prevent the problem but it could help locate the problem.

[infinitenothing]

Yes, and those are great because there is a time out feature that allows the application to continue, recover and provide useful information for fixing the problem.  Do you also mean storing the object itself in a SEQ instead of sharing a DVR?  Does that mean that all of your class methods must be surrounded by the Dequeue/Enqueue?

 

Your class type has the queue in it. Your accessors have to dequeue-modify-enqueue with a timeout as an input. You have to have a Create-Run-Destroy architecture.

Edited August 20, 2015 by infinitenothing

[ak_nz]

Yes, and those are great because there is a time out feature that allows the application to continue, recover and provide useful information for fixing the problem.  Do you also mean storing the object itself in a SEQ instead of sharing a DVR?  Does that mean that all of your class methods must be surrounded by the Dequeue/Enqueue?

 

I don't think that the idea is to use DVR to lock a resource.   For many of our objects, we call methods on them using DVR (ByRef).  Every now and then, we realize that two objects end up with a circular dependency that was not expected and we experience a deadlock that just cannot be recovered from. 

 

I appreciate that limiting the use of DVRs to basic accessors reduces the risk but it also restricts us from using more useful methods that are properly protected inside the object.  Drawing the line can be challenging between reducing the risk and protecting class methods.  Is there any VI Analyzer functions that allow for automatic check for an IPE inside an IPE where both have a DVR?  It may not prevent the problem but it could help locate the problem.

 

Welcome to the wonderful world of references, right? You can see the lack of time-out on the DVR as a mild objection to reference-based designs from R&D. Personally we store the DVR in the private data of the class; the DVR is never exposed to callers.

 

As far as I know there are no in-built VI Analyzer checks, though I can see that it wouldn't be too hard to create your own.

[eberaud]

I'm not a fan of using queues to wrap a DVR, since the whole point of DVR is to have an efficient way to read-modify-write a value in memory while guaranteeing its integrity. We make heavy use of DVR and it works like a charm now. During the development phase though, we did run in deadlocks and it's true that a timeout would have made our lives better. But I don't think the final architecture should use DVR timeouts as part of the design. They should only be here to signal an error and be treated as such.

[smithd]

Are we a very small minority to use this DVR and IPE with objects and sometimes run into circular references during development?  Are others actually implementing their own Semaphores manually before the IPE structure?  Is there a clean and simple solution that I am not aware of to circumvent this problem?

 

I am curious to know how people are fairing with this issue and if more people are interested, to make the suggestion from Chris more popular.

Definitely a small minority, since you'd have to have some way of creating a circular reference, but if you absolutely need that functionality I'm pretty sure everyone runs into it eventually. I hadn't thought of the semaphore but thats an interesting point. I don't know of any way to fix the issue. It gets especially tricky with property nodes on classes, since there isn't even an explicit IPE there. It just hangs

[OlivierL]

I'm not a fan of using queues to wrap a DVR, since the whole point of DVR is to have an efficient way to read-modify-write a value in memory while guaranteeing its integrity. We make heavy use of DVR and it works like a charm now. During the development phase though, we did run in deadlocks and it's true that a timeout would have made our lives better. But I don't think the final architecture should use DVR timeouts as part of the design. They should only be here to signal an error and be treated as such.

I agree with you, from our design perspective, that that Timeout should not be used as a regular lock mechanism and that a SEQ or semaphore is a better way to do it.  However, that is probably up to the developers to decide how they would like to use that new option. We would use it as a protection and a simple way to prevent complete systems "freeze", but it could offer more benefits that we do not foresee at the moment.

 

Welcome to the wonderful world of references, right? You can see the lack of time-out on the DVR as a mild objection to reference-based designs from R&D. Personally we store the DVR in the private data of the class; the DVR is never exposed to callers.

Yes, I guess that the fact that "ByRef" objects cannot use dynamic dispatch is another example of R&D'S reluctance to references!  But even if the DVR is inside the private data of the object, you could absolutely run into the same circular reference bug that I describe.  That does not protect you in any way, does it?

 

Your class type has the queue in it. Your accessors have to dequeue-modify-enqueue with a timeout as an input. You have to have a Create-Run-Destroy architecture.

So you don't have a reference to an object, you have the object itself and the private data is a Queue, right?  This is very similar to including the DVR inside the private data.  It is definitely another way to implement a similar solution and but are protected against circular references "hang" with aproper timeout. One benefit of the DVR access method is for objects who owns large amount of data (large arrays for graphing for example), there is no need to make memory copies in the same way that the SEQ does.  That was also one of our reason to choose the DVR and ByRef methods for certain objects.