In Place Element Structure to lock all types of References

[crandiba]

Hi all,

I recently came across the need to lock a FPGA ref during some operations to prevent a race condition. While implementing, I naturally thought it would perhaps be simpler to implement using the same mechanism the In Place Element Structure uses to lock the DVR reference. As such, whatever reference wired into the IPES would have the option of being marked as "Blocking".

I have no idea if this is a small change or a huge effort to implement, but I think it can help in managing resources more efficiently - or at least with less steps.

Best,

Cris

[crossrulz]

That would be a huge effort as the blocking mechanism would have to be added to all reference types (and there are a lot of them).  You can accomplish what you want with an Action Engine, Semaphore, or DVR.

[crandiba]

Hi Crossrulz,

Thanks for the feedback and suggestion; I lazily wanted to spare myself the trouble of attaching/encapsulating the reference with a semaphore/DVR or other mutex, so I thought the IPES would be nice and quite convenient. I had hoped the blocking mechanism would be a more "ancestral" property of the reference class, higher up in the hierarchy and as such, easily set for all refnum types.

Thanks again!

[AristosQueue (NI)]

crandiba:

This idea is impossible without changing the code that users write in a pretty significant way. It certainly wouldn't be possible with existing refnums. Here's why...

The caller has an In-place Element structure (IPE) that locks the refnum. Inside the IPE, the caller passes the refnum into a subVI. The subVI is compiled to be called by any caller -- it doesn't know whether the refnum is locked or not. So it will try to acquire the lock for any operation it does on the refnum. And it will deadlock if the caller is already holding the lock.

That means that we would need to create two refnum types for every existing refnum. For example, you would have "Locked queue refnum" and "Unlocked queue refnum", and a subVI would only be able to take one or the other. Trying to pass the "is it already locked" information in the connector pane won't work -- what if it is an array of refnums? Or deeply embedded inside the cluster/class/DVR/etc. that is being passed along?

But having an "unlocked queue refnum" type creates a bigger problem. We'd have to block it from being passed in queues/variables/clusters/classes/variants... anything that could smuggle the refnum out of the IPE and allow it to be used after the lock is released.

It gets really messy really fast.

Try to avoid using refnums entirely. If you must use them, use them inside non-reentrant VIs to prevent collisions. If that doesn't work, wrap your refnums in a DVR or pair them with a semaphore. Those are your G tools, and they're as good as it is likely to get.

[crandiba]

Hi AristosQueue,

Thanks a lot for laying things bare and the great explanation - as always. I imagined an the locking as some sort of singleton as part of the refnum itself, and so every call would be able to check if is locked or not and timeout/error. I lacked the foresight and knowledge you eloquently exposed and really thanks again for always having the consideration to go the extra step in providing explanations and examples. I will most likely do as you guys suggested and wrap it in a DVR or something; could even be a good moment to look into the extensible session framework.

Thanks again!

[AristosQueue (NI)]

Sorry to bear bad news on this one. We continue to look at better ways to handle refnums. In a parallel environment, they are a very non-trivial problem.

[Darren]

Declined for reasons listed by AristosQueue in the idea discussion thread.