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.
05-13-2020 10:56 AM
I have two instances of an actor each controlling an identical piece of hardware. When troubleshooting with the DETT, I noticed that when the same message is sent to both instances, the second to receive the message does not call its public method until the first one has completely executed its public method (this is running emulation code in place of the hardware).
I have many other actors running in this application, so I was wondering if this behavior could be due simply to limitations with processor cores/threads?
Solved! Go to Solution.
05-13-2020 11:12 AM
It sounds like you have the public method set to non-reentrant. You can change this by setting the reetrancy to shared-clone or preallocated-clone mode in the VI settings.
https://zone.ni.com/reference/en-XX/help/372614J-01/lvconcepts/reentrancy/
05-13-2020 12:50 PM
mbremer's answer sounds correct. Remember that you need to make the method VI be reentrant and also make any subVIs that it calls also be reentrant (unless they are short, incidental VIs and the minor thread friction doesn't bother your application).
05-13-2020 01:00 PM
You are right. I assumed that the dynamic dispatch VIs were set to reentrant as is Actor Core. So for any actors for which I launch more than one instance, I will need to set all their methods reentrancy to "reentrant".
05-13-2020 01:19 PM
@BillMe wrote:
You are right. I assumed that the dynamic dispatch VIs were set to reentrant as is Actor Core. So for any actors for which I launch more than one instance, I will need to set all their methods reentrancy to "reentrant".
Correct... if those methods are long-running and causing performance bottleneck. Remember that reentrancy is a space-vs-time tradeoff, which is why VIs are not reentrant by default. As a general rule, yes, you want more reentrancy in actors that are running in parallel with themselves, but I hesitate to say "always" because blind application of that rule can lead to bloated applications that lose performance on memory swaps. For small applications, doing "everything is reentrant" is fine.