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.
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.
09-03-2010 09:30 AM
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?
09-03-2010 10:02 AM
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
09-03-2010 10:24 AM
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.
09-03-2010 10:27 AM - edited 09-03-2010 10:27 AM
My application contains motion and needs as much performance as it can get. Therefore all unnecessary blocks and Context Switches should be avoided.
09-03-2010 10:31 AM - edited 09-03-2010 10:32 AM
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
09-04-2010 12:27 PM
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.