Jump to content

Execution system "same as caller"


Recommended Posts

Hi guys

I have a couple of questions regarding the "same as caller" execution system, which is set as a default value in VI's execution properties.

  • I understand the subVI inherits the execution system from its calling VI. Now does it inherit the calling VI's exec system if it's called dynamically, i.e. either by Call by Reference or by Invoke Node?
  • Is there any way how to determine the running VI's actual execution system?

The multithreading model of LV is quite interesting, but there is only a little information about it in LV help, which moreover seems to me a bit outdated. Do you know about any other information sources?

Vladimir

Link to comment

  • I understand the subVI inherits the execution system from its calling VI. Now does it inherit the calling VI's exec system if it's called dynamically, i.e. either by Call by Reference or by Invoke Node?

When called using Call By Reference, yes, it has the same as its caller. The CBR node treats the new VI as a subVI. When you start a VI running using the Invoke Node "run" method, no, the execution system is not same as caller because there is no caller. The Run method is the same as running a VI top-level (as if you hit the run arrow on it).

  • Is there any way how to determine the running VI's actual execution system?

Don't know and never needed to know. Mark VIs that need to be "user interface" to be "user interface" and let all other VIs follow the lead of their caller.

> which moreover seems to me a bit outdated.

How so? It's the same threading model used by the OS, and it translates directly to modern FPGAs. What aspect are you seeing that feels stale?

Link to comment

Hi

Thanks for the explanation. What seemed to me as outdated was the statement in the documentation that each execution system and each priority is running two threads. However, due to my experiments, it seems to be actually four threads. In the beginning, this was a bit misleading and I did not know if the other information is current or not.

Vladimir

Link to comment

"Preferred Exec System" is a standard (not even hidden) property of the "VI" VI Server class.

1. Put a property node (located on the Application Control pallette) on the block diagram.

2. Right-click on it and in the pop-up menu select: Select Class/VI Server/VI/VI.

3. Left click on the "property" word on this property node (which is now for VI class). In the pop-up menu select: Execution/Preferred Exec System

You don't need to wire the reference input. When not wired the calling VI is assumed to be the VI for which properties are set/read.

Link to comment

QUOTE(Vladimir Drzik @ Dec 4 2007, 03:25 AM)

Hi

Thanks for the explanation. What seemed to me as outdated was the statement in the documentation that each execution system and each priority is running two threads. However, due to my experiments, it seems to be actually four threads. In the beginning, this was a bit misleading and I did not know if the other information is current or not.

Well the number of threads per execution system is a not so interesting detail, IMHO. LabVIEW initialy used as default 1 I think then increased to 2 and then 4 but in 8.5 this is actually more dynamic based on the number of CPU cores LabVIEW can find in the system. Even before that this number was not set in stone but could be user configured with a somewhat hidden VI in vi.lib/Utility/sysinfo.llb/threadConfig.vi. That configuration is written into the LabVIEW ini file and in such a way can be transfered to a built application too.

Rolf Kalbermatter

Link to comment

Hi Rolf

Thanks for the information, this is something I missed in the documentation. The number of threads per exec system can be interesting for me, because I'm using a lot of time-consuming DLL calls, which cannot be switched by the LV exec system. Do you know where I can find the information about dependence of number of threads on the number of processor cores in LV 8.5?

Vladimir

Link to comment

QUOTE(Vladimir Drzik @ Dec 6 2007, 06:33 AM)

Hi Rolf

Thanks for the information, this is something I missed in the documentation. The number of threads per exec system can be interesting for me, because I'm using a lot of time-consuming DLL calls, which cannot be switched by the LV exec system. Do you know where I can find the information about dependence of number of threads on the number of processor cores in LV 8.5?

Vladimir

I was attending a presentation during the LV days all over the world that followed the NI week. The presenter, an active LabVIEW developer much into especially these areas of LabVIEW, only said that the number of executions systems was now more dynamical depending on the actual number of cores LabVIEW could find. He didn't say specific numbers because I think that is hard to do anyhow. There is most probably some heuristics involved that use to some point somewhat arbitrarily chosen values, with lots of tweaking, testing and such during the devlopment.

And those heuristics will likely change again as different multi-core designs get available, different CPU architectures are introduced and different OS support is introduced.

One possible starting point is above mentioned VI. It should give you an idea about what the currently used setup is for any particular machine. Interestingly on my system, an Intel Dual core machine it reports 4 CPUs :D

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.