LabVIEW
Different Semaphore references for the same semaphore?
Solved!
Hi,
I'm wondering why the VI below outputs different semaphore references. So far I assumed that they will be the same.
Thanks!
You get different references to the same object.
Internally, semaphores are just queues.
This will also return false.
Different reference to the same object.
However, if you somehow get two references to a GObject (controls, nodes, wires, etc.) a compare of a different reference to the same object will return true...
So it doesn't seem wrong, but it is a bit inconsistent.
Search LabVIEW like a graph!
@GerdW wrote:
Hi 1984,
@1984 wrote:
So far I assumed that they will be the same.
Why did you?
You create a bunch of semaphores: each will be a new one with its own reference. But they may point to the same (LabVIEW internal) control structure…
But they are not new semaphores. The created new output is false.
So, new references to the same object.
Comparing other references does return true if the reference is different, but pointing to the same object.
The good old problem of all higher level object oriented languages like Java and C#. Should an object reference comparison return true or false if the references are different but pointing to the same object. The default is to compare the reference itself and hence return false for the isEqual() method. If you want a different behaviour you have to overwrite the class method isEqual() and do an explicit comparison of the relevant class private data or whatever it is your object contains.
LabVIEW does this internally for the VI Server objects (but didn't always do that in the past). Not so for other refnum types however. I don't think that the object manager interface that is responsible for managing refnums actually supports a comparison method, so the Equal operator has to delegate to refnum specific methods in the case of VI Server refnums. Not a clean design, but after more than 35 years of development such inconsistencies are simply impossible to avoid.
They tried an experiment in the early 90ies of last century to compile LabVIEW in C++. At that time the generated executable size was exploding because of that and with 4 to 8 MB of RAM being the standard in computers at that time it was simply not an option. So they stayed with C code for several more years before starting to develop all new features in C++ only.
@1984 wrote:
Because I'm certainly not as clever as some other people and I usually make false assumptions.
I thought that with whatever internal mechanism once a semaphore reference is created then if we'd like to create it again it will return the same reference. I'm clearly wrong as the VI above demonstrates, I was just surprized and wondering about the reason.
What do you mean on "but they may point to the same (LabVIEW internal) control structure". Is it possible that they are not?
Thx.
It doesn't matter.
They do point to the same semaphores, but with a different reference.
And for different references to the same object, LV does often return true when compared:
For semaphores (and queues) it's a bit different (because they need to be created and should be destroyed) but I don't think you made a weird assumption.
@GerdW wrote:
Hi 1984,
@1984 wrote:
What do you mean on "but they may point to the same (LabVIEW internal) control structure". Is it possible that they are not?
See wiebe's reply above, he already explained the behaviour…
A key difference between the control and semaphore references is you get the control refs, you create the semaphore refs.
If you close a control ref, and ask for it again (in the same way), you will get the exact same reference. In other words: the close didn't actually do anything, because the ref is simply there and wasn't created by asking for it (it was created when the VI ref was opened).
I'm not sure if this is why the compare behaves differently, but it seems related. NI could just as well have simply decided "VI Server refs: yes, other refs: no".
