From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Should Release Semaphore Reference.vi be Reentrant?

I am getting the following message from the VI Analyzer:

 

"The subVI named "Release Semaphore Reference.vi" is not reentrant. Multiple instances of reentrant VIs cannot run in parallel if that reentrant VI calls a non-reentrant subVI. One reentrant instance will have to wait on the execution of that subVI if it is currently running in the other instance. Consider making this subVI reentrant so multiple instances of its parent VI can run in parallel."

 

Is it correct? Should Release Semaphore Reference.vi be Reentrant? What is the harm if it is made reentrant? Usually it is called only one at a time for any given semaphore.

 

What about simultaneously Releasing several different semaphores at the same time?

 

What do you think about changing it?

0 Kudos
Message 1 of 6
(3,040 Views)

I think the execution of this VI is so fast that you should not have any problem even if it is not reentrant.

Anyhow what you could do is to generate a reference to the semaphore and propagate it through all your code, and call "Release Semaphore Reference.vi" only once, when you exit...

 

Marco

0 Kudos
Message 2 of 6
(3,031 Views)

To use a semaphore, Acquire Semaphore has to be called before every critical section and Release Semaphore has to becalled after every critical section.

 

So in an application there should be a minimum of 2 each. Of course there may be more than one semaphore used in an application.

 

 

0 Kudos
Message 3 of 6
(3,025 Views)

My application contains motion and needs as much performance as it can get. Therefore all unnecessary blocks and Context Switches should be avoided.

 

 

0 Kudos
Message 4 of 6
(3,022 Views)

You are right when speaking about "Release Semaphore".

But I was speaking about the vi "Release Semaphore Reference" mentioned in the message from the VI Analyzer.

 

Regards,

Marco

0 Kudos
Message 5 of 6
(3,017 Views)

I don't really use semaphores, but I'm going to agree with Marco - the time it should take LV to close the reference is minimal (and probably only happens at the end of operations anyway), so I would ignore it. I don't use VI Analyzer, so I don't know why it gave you the warning for that VI specifically. Presumably you call it inside reentrant VIs.

 

Also, if your application need real-time performance characteristics, it should be run on a real-time target and designed by someone who knows how to design such applications.

 

In any case, it is highly recommended to AVOID modifying VIs which ship with LV. Just leave them as they are.

 

Incidentally, you should be aware that making a VI reentrant is a trade off between potential parallelism and resource allocation. If there was no trade off, you could just make most VIs reentrant. This changed to a degree with the shared pool reentrancy option, but in general you should not make a VI reentrant unless it either needs that functionality or you have good reason to believe you'll need the parallel execution.

 

As a side point, I believe the text from VIA is badly phrased:

 


Multiple instances of reentrant VIs cannot run in parallel if that reentrant VI calls a non-reentrant subVI.

They can and will run in parallel, but they will have to wait on each other if they both want the subVI at the same time. This is what the next sentence explains, but the first one is confusing.

 


___________________
Try to take over the world!
0 Kudos
Message 6 of 6
(2,978 Views)