Timeout for In Place Element Structure with DVR nodes

[Chris_Cilino]

The In Place Element (IPE) is great and so are Data Value References (DVRs).... but... well sometimes I'm not such a great programmer and I will cause a dead lock in my code causing what looks like a "hang". Debugging can be hard in that case when trying to figure out which vi was trying to access the DVR. Also if I'm using the dvr for some sort of global storage, i may want an error to ocurr if some piece of code holds onto the DVR lock for too long. 

I'd love for the IPE to have a timeout when you have 1 or more DVRs and if ALL of the references are not available in the specified time, the structure returns an error. 

[AristosQueue (NI)]

This feature already exists in LabVIEW. It is implemented in hardware through our NI-User device -- properly configured, the NI-User will eventually exaust its patience and trigger a mouse click event on the Abort button. 😉

On a more serious note...

> i may want an error to ocurr if some piece of code holds onto the DVR lock for too long.

The error would not occur in the offending code but occurs in the well-behaved code that was waiting for the DVR. So this wouldn't help you with debugging because you'd still need to go searching for whatever function it was that was holding the lock -- that's where your bug is located.

[sbus]

Just because the error occures in the code waiting for the lock doesn't mean the timeout isn't useful. I'd like to see the timeout value actually be an input to New Data Value Reference; that way you could set the timeout differently for each DVR.

When the tiimeout occurs, it should exit the in-place element structure with an error code indicating a DVR timeout occurred. That means that the in-place element would require an ouput (a boolean?) indicating that  it exited due to timeout.

I'd also like a way to figure out which DVR timed out. My preference would be to add a 'name' string as input to New Data Value Reference, so we can name DVRs. The in-place element could also include an ouput that (valid only when the timeout output is TRUE) that is the name of the (first) DVR that timed out.

Even if the reason the timeout occurs is due to external code, recovery from deadlock is still polite behavior; and providing status to indicate why the recovery was necessary is helpful for debugging.

[OlivierL]

I think that this feature would be very helpful. DVR of objects are very useful but sometimes we can run into race conditions or circular calling and I would much rather get an error than my code hanging for forever...That would save us a ton of time and make troubleshooting a lot easier.  I could add Semaphores before each access but that is burdensome and would be better handled in the IPE structure itself.

I would suggest the following behavior:

 - If there is a DVR Read/Write, then there could be a Timeout as an input to that specific read.  This way, different Read/Write could have different Timeouts if need be.  I think that Chris suggestion is also valid, there could be a single Timeout for the whole In Place structure (and that terminal could be enabled from the Right-Click menu)

 - If the timeout option is enabled, then the in Place Element structure could automatically add a Error/No Error case (not as part of the IPE itself!) so that the user can write different code when the DVR has not been acquired.  This could also be handled by the user who manually adds the Case structure but I think it would be nice to have the forced Error Case to make it obvious that your processing cannot proceed normally.

 - In the "DVR Read Error" case, the error cluster out of the "Read" node should have a given error code with a detailed message saying which VI currently holds the DVR reference. <-- probably the most useful portion to address the problems 

 - Any other nodes in the in-place element could still perform its duty normally

[Taylorh140]

Is this possible with another method? I could use this right now.

[RavensFan]

I think you'd have to use other methods to protect the structure such as a semaphore or rendezvous.  By the time you implement them, you find you might not need the In Place Element structure anymore.

[AristosQueue (NI)]

Taylor_H: Just use a queue bounded to size 1. It is not as efficient as a DVR -- largely because it has timeout behaviors! -- but it is what people used before DVRs were introduced. The single-element queue (SEQ) works by creating it with max size 1, then immediately enqueueing an element into it.Thereafter, when you want to access the data, do a dequeue, and when you're done, do an enqueue. Everyone else trying to do a dequeue at the same time will block until the data is available... or until a timeout occurs.

[Thomas_robertson]

I would very much like this feature.  Frozen in place structures because some other piece of code has run amok is horrible.   Being able to detect it is much better.

[Chris_Cilino]

NI any updates on this?

[AristosQueue (NI)]

Speaking for NI: I seriously doubt it will ever be acted upon for reasons I mentioned earlier unless there was an overwhelming cry from the community for it:

a) adding timeout support would reduce DVR performance even for those not using it

b) it is not commonly needed functionality, and

c) there is a workaround (single element queue) for those people who really need this functionality. 

22 kudos does not overwhelm.

Speaking purely for myself: If I found myself needing timeout behavior for arbitrary function invocation, that would raise a red flag for me in my design. Polling loops for retry can quickly become a performance burden, and there's a high risk of introducing operation starvation in this kind of design. As soon as I found myself wanting it, I would quickly be looking at why and whether I can eliminate that desire from my architecture. When I look beyond LabVIEW, I note that most mutex locks on data that I have worked with do not support timeouts for acquiring the lock. Given all that, I would not personally advocate for this idea.