LabVIEW
Type cast Queue to Rendezvous reference
Hello all,
Can someone please explain the below code, particularly the Type cast Queue to Rendezvous reference?
The control input size (2) is wired with a constant value of 4.
What will this conversion/code actually do?
@battler. wrote:
@RavensFan wrote:
It doesn't make any sense to me.
Where did you get this from?
That's not a good sign.
A contractor created it for me.
Don't worry. This is actually core LabVIEW code provided by NI, not your contractor. I believe the typecasting is to sort of hide what's going on under the hood. If they exposed it as a regular Queue, then people might try to enqueue something or otherwise "mess with it". This way they obfuscate the actual guts of the Rendezvous and "black box" the whole thing.
If you go to the Synchronization palette, select Rendezvous, then Create Rendezvous. Within that VI you will find "Create New Rendezvous", which is this code here. Your contractor didn't make that; it's part of what LabVIEW is.
You can safely ignore it. While I personally haven't used one before, Rendezvous are used to synchronize two different parts of code. You create one reference to a Rendezvous, then branch it to a few places in your code. When you create it, you tell it a "size". Let's say the size is 3. When the first piece of code gets to "Wait for Rendezvous", it sees it's the first one there, and waits. The second one gets there, sees it's the second one out of three required, and waits. The third one gets there and sees it's fulfilled the Rendezvous, and all three pieces of code begin executing immediately. I would recommend ignoring what's going on under the hood unless you have a REALLY good reason to do so. Rendezvous' have been part of LabVIEW for a very long time and are (AFAIK) thoroughly debugged.
@battler. wrote:
Question, so if you create a Queue with Threshold of 4 (is this maximum 4 elements?) then Typecast it to a reference does it create 4 x the references? I guess not because it's not an array of references...
You do not need to typecast Queue references. I can only guess at NI's intentions, but I assume they do this to intentionally obfuscate the code and make it hard to understand. They probably just typecast it right back to a Queue reference anywhere they actually use it (they do this at least in Wait for Rendezvous). I think converting it to a reference is sort of "packing it up" behind a wall, similar to putting it into a zip file or into an LVClass. In other words, no VI's other than the Rendezvous ones can mess around with the internal data. The size is just an internal variable value, not a number of references. If you need to create a rendezvous, I would first reconsider whether or not you need to do it, and if you really do, just use them as they are in the palette. Trying to "make your own" is going to be difficult.
Do you really need to understand how the Rendezvous works internally to understand your contractor's code?
@tst wrote:
Originally, both RVs and semaphores were implemented using a code interface node (CIN) and had their own reference wire types. At some point (around the 8.0-2009 timeframe, I believe) NI decided to change the internal code (probably in order to get rid of the CIN, which they wanted to deprecate),
Actually all the Synchronization libraries (Queues, Notifiers, Semaphores, Rendevous) were built around a CIN that managed the objects and used the typed log file refnum trick to provide a protection against wiring this object refnum to something else than the apropriate functions. The value behind the refnum was in those times really a sort of pointer and the implementation followed (or probably set the tone for) the LVOOP model before LabVIEW had its own GOOP implementation.
Eventually NI implemented the Queue and Notifiers as a native LabVIEW object and replaced the VIs with native nodes and a few hidden compatibility VIs. Removal of CINs was one motivation for this but certainly not the only one. Another was the anticipated move to 64-bit support which would have catastrophally failed those old implementations that typecasted a pointer into a 32-bit LabVIEW refnum. So a redesign was anyhow needed.
Now adding a new refnum type to LabVIEW is a pretty complex operation where many things in the LabVIEW code base, as well as internal and external documentation and what else needs to be taken care of, so it's not something that is done on a mere whim and without really good reasons. Also developing and especially testing the C code for these objects to be 100% multhreading safe even on multicore monsters is not an easy task either.
Dropping of the not so often used Semaphores and especially Rendevous was not an option, but reimplementing them on top of Queues is a proven technique and only requires to test and proof that the Queues themselve are fully multithreading safe (which they haven't been in the past in some rare corner cases).
So the VIs for these objects were reimplemented with the old connector pane and "faked" object refnum on top of queues. The Typecast from the Queue refnum to a "Semaphore" or "Rendevous" refnum is mostly a No-Op at runtime. It's purpose is to hide the actual Queue implementation from any user of the objects so they can't inadvertedly mess with the implementation. If they had just exposed the queue refnum, it would be way to easy for even experienced LabVIEW programmers to accidentially miswire things and by accessing the queue in other ways then the published API you could make it misfunction. Yes you still can (the diagram is unlocked and you can see what is done in there, but it is not the LabVIEW developers task to prevent someone from shooting in their own feet, if they absolutely insist in doing so).
And I agree with tst, calling this obfuscation is not at its place. The diagram is fully viewable and pretty well documented. It's more for the users benefit in attempting to prevent them to shoot themselves by accident than anything else.
