LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Semaphore GOOP Help

My Quandry:
 
I am dynamically launching multiple VIs, but I am interested in them sharing a single resource (say, data stored in a GOOP-style/Old-style global.). So I want to use a semaphore to coordinate which VI has access to the resource.
 
I have a VI that calls the object VI, which creates the semaphore and stores it in its shift register. Then I dynamically launch the resource(s) that use the object VI.
 
What I find is that the semaphore becomes invalid the minute that the top-level VI (which set everything up) is done.
 
This makes no sense to me, as the refnum is stored in a shift register in a subVI that is contained by an executing VI.
 
It is also causing me a big problem in my application.
 
Who can explain this?
 
SEE EXAMPLE.
 
Note: the example was written in 7.1, but also evidences the behavior in 8.0
0 Kudos
Message 1 of 8
(3,800 Views)
Sorry I cant open the code because I still run 7.0 over here but I think I follow your question anyway, you launch a subvi which uses a resource, and the resource has a semaphore associated with it which is passed from the toplevel vi, and you want the subvi to stop when the main vi is stopped.  You could possible monitor the status of the semaphore in the subvi (in its own thread) and when the semahpore has been destroyed (from the top level vi), you stop the execution of the subvi.  I would have to see the example in 7.0 to see if I followed you correctly.   
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 2 of 8
(3,789 Views)

The refnum itself is not enough to keep the semaphore. It is only a "pointer" to it. Once the top level VI stops running, LV does automatic garbage collection and destroys the semaphores created by the hierarchy, even if the subVI which created the semaphore is still in memory. You still have the pointer, but it is now worthless.

I'm not sure myself whether this behavior is correct. Perhaps a semaphore should not be closed if VIs accessing it are still in memory. It sounds reasonable, but I haven't put the same amount of thought into it which I hope the NI people have.

As a workaround, can you try adapting one of the other synchronization mechanisms? The configuration file VIs, for instance, use pure G to create the refnums and so you could adapt that and it should stay in memory.

___________________
Try to take over the world!
Message 3 of 8
(3,786 Views)

Once the pointer is worthless, the semaphore vi will return an arrar which can be used to stop the subvi, I do this all the time with queues, where thare are several loops which are using the queue to communicate, when I stop destroy the queue from another "top level vi" or even any of the subvi then I have an event to stop all vi's which depend on the resource.

 

 

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 4 of 8
(3,784 Views)

Paul, the original poster wants to keep the semaphore, since the top level VI is only used to call the other VI dynamically and then it is closed. Using a pure G approach to get the refnums resolves this problem, since the refnums remain valid.

The other option is to keep the top level VI in memory by opening a reference to itself and hiding it FP, so it's not in the way.


___________________
Try to take over the world!
Message 5 of 8
(3,777 Views)

Lets see if I can add some value without getting stuck!

There is a size input fo rthe create semaphore.

That determines how many enities can get the semaphore.

When a semaphore is requested and obtained, that value gets decremented. When the value is zero, nobody else get the semaphore. When the semaphore is released tha value is incremented.

This how LV tracks if the semhpre is in use.

When a VI evaluated to determine if it can be unloaded the resource taht were allocated by that VI are checked to see if they are in use. That is done by looking a the semaphore count and the max size.

So...

1) When the semaphore is created set the size = 2

2) Imediately after creating it, acquire the semaphore. (that should leave one for everyone else).

3) Everything else codes the same until the end.

4) At shutdown time, the entity that will destroy the semaphore should do a "release" prior to the destruction.

I have not tested this but this is how I understand it and what I would try if I was faced with this challenge.

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 6 of 8
(3,763 Views)

No, Ben, that doesn't work.

By the way, this behavior is very clearly stated in the help for Create Semaphore:


Note  A named semaphore exists only as long as the top-level VI that first created the named semaphore continues running. For example, if Application.vi has a subVI Subtask.vi, any named semaphores created by Subtask.vi are cleaned up when Application.vi stops executing. You can use the same named semaphore in any VI—even those not in the hierarchy of Application.vi—but the semaphore ceases to exist when the Application.vi hierarchy shuts down.

 

___________________
Try to take over the world!
Message 7 of 8
(3,758 Views)

Thanks tst!

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 8
(3,752 Views)