LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Different Semaphore references for the same semaphore?

Solved!
Go to solution

Hi,

 

I'm wondering why the VI below outputs different semaphore references. So far I assumed that they will be the same.

 

Thanks!

 

Semaphore references.png

 

1984_0-1678957613315.png

 

0 Kudos
Message 1 of 11
(1,202 Views)

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…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 11
(1,196 Views)

You get different references to the same object.

 

Internally, semaphores are just queues.

 

wiebeCARYA_0-1678958109288.png

 

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.

0 Kudos
Message 3 of 11
(1,188 Views)

@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.

0 Kudos
Message 4 of 11
(1,186 Views)

Because I'm certainly not as clever as some other people and I often 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.

0 Kudos
Message 5 of 11
(1,179 Views)
Solution
Accepted by 1984

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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 11
(1,171 Views)

@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:

Different References Compares True.png

 

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.

0 Kudos
Message 7 of 11
(1,168 Views)

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…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 8 of 11
(1,165 Views)

@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".

0 Kudos
Message 9 of 11
(1,147 Views)

Thanks for the insights. Multiple answers could be accepted as a solution so I had to make an arbitrary decision.

0 Kudos
Message 10 of 11
(1,083 Views)