Multitasking not working while calling DLL

[hulaj]

This is my problem:

I have LV DLL based driver, every function in this driver is
reentrant, every DLL call is reentrant.
I want to communicate with number if instruments via this driver.
So I programatically clone the VI which communicates with instrument.

When I run all cloned VIs in parallel to communicate with all
instruments, the DLL calls are executed sequentialy.

Why there are not able to dynamically generate new threads ?

[Greg_McKaskle2]

> I have LV DLL based driver, every function in this driver is
> reentrant, every DLL call is reentrant.
> I want to communicate with number if instruments via this driver.
> So I programatically clone the VI which communicates with instrument.
>
> When I run all cloned VIs in parallel to communicate with all
> instruments, the DLL calls are executed sequentialy.
>
> Why there are not able to dynamically generate new threads ?

It sounds like you have most of the correct settings, but let me review
them anyway. First, make sure that threading is on in the
Tools>>Options on the Execution page. It defaults to on, but sometimes
gets turned off for compatibility with ActiveX or other nonthread
friendly programs.

Second, you say that your DLL calls are reentrant. If that means that
the Call Library Function nodes have their checkbox set to show that the
call can be made reentrantly, and making their color yellow instead of
orange, then step two is taken care of. Otherwise make this change.
You also mention that you cloned VIs. If you are using the same VI in
more than one place on the diagram, they default to making a critical
section -- allowing only one caller at a time. If you want to allow
reentrant execution, this is set in VI Properties.

Third, which I think is what is going wrong in your case, you need to
have enough threads or execution systems to run your VI. You ask why LV
doesn't generate dynamic threads. The answer is that LV preallocates
threads that the VI needs to run and schedules nodes on those threads
according to dataflow. Creating and destroying threads is actually
quite expensive on most OSes, so that is not the mechanism LV uses.

Here are several solutions for your system. Each VI and subVI can be
set to run in a particular execution system and at a particular priority
using the VI Properties>>Execution page. On a single processor computer
each execution system priority cell defaults to having one thread. On a
dual processor it defaults to having two, a quad defaults to four. In
most cases this ends up being sufficient to keep the processors busy
without causing excessive thread swaps.

In the case where your threads are being consumed by a DLL call and
therefore cannot multitask with the other dataflow nodes, you can either
set your VIs to run in the different execution systems, or you can make
the Standard execution system have more threads.

To set the execution system of a VI, use the VI Properties. To change
the threads per execution system, open the
vi.lib/utilities/sysinfo.llb/threadcfg.vi or something very close to
that name. This VI shows the threads allocated per cell, and hitting
the config button at the bottom lets you change it. Note that as of LV6
these numbers are the maximum limit allocated by LV and it doesn't
allocate the threads in an execution cell until a VI is loaded that
needs that system/priority.

Now that I've told you how to do it, I'd recommend doing a very quick
experiment with the execution system settings to see if there is any
advantage to having multiple threads active. If the various threads are
sleeping/waiting for hardware, this may indeed allow other threads to
make progress, but if they are doing a spin-lock or heavy computation,
there really isn't any benefit.

Greg McKaskle

[hulaj]

Greg McKaskle wrote in message news:<3D7372B8.2020309@austin.rr.com>...
> > I have LV DLL based driver, every function in this driver is
> > reentrant, every DLL call is reentrant.
> > I want to communicate with number if instruments via this driver.
> > So I programatically clone the VI which communicates with instrument.
> >
> > When I run all cloned VIs in parallel to communicate with all
> > instruments, the DLL calls are executed sequentialy.
> >
> > Why there are not able to dynamically generate new threads ?
>
> It sounds like you have most of the correct settings, but let me review
> them anyway. First, make sure that threading is on in the
> Tools>>Options on the Execution page. It defaults to on, but sometimes
> gets turned off for compatibility with ActiveX or other nonthread
> friendly programs.
>
> Second, you say that your DLL calls are reentrant. If that means that
> the Call Library Function nodes have their checkbox set to show that the
> call can be made reentrantly, and making their color yellow instead of
> orange, then step two is taken care of. Otherwise make this change.
> You also mention that you cloned VIs. If you are using the same VI in
> more than one place on the diagram, they default to making a critical
> section -- allowing only one caller at a time. If you want to allow
> reentrant execution, this is set in VI Properties.
>
> Third, which I think is what is going wrong in your case, you need to
> have enough threads or execution systems to run your VI. You ask why LV
> doesn't generate dynamic threads. The answer is that LV preallocates
> threads that the VI needs to run and schedules nodes on those threads
> according to dataflow. Creating and destroying threads is actually
> quite expensive on most OSes, so that is not the mechanism LV uses.
>
> Here are several solutions for your system. Each VI and subVI can be
> set to run in a particular execution system and at a particular priority
> using the VI Properties>>Execution page. On a single processor computer
> each execution system priority cell defaults to having one thread. On a
> dual processor it defaults to having two, a quad defaults to four. In
> most cases this ends up being sufficient to keep the processors busy
> without causing excessive thread swaps.
>
> In the case where your threads are being consumed by a DLL call and
> therefore cannot multitask with the other dataflow nodes, you can either
> set your VIs to run in the different execution systems, or you can make
> the Standard execution system have more threads.
>
> To set the execution system of a VI, use the VI Properties. To change
> the threads per execution system, open the
> vi.lib/utilities/sysinfo.llb/threadcfg.vi or something very close to
> that name. This VI shows the threads allocated per cell, and hitting
> the config button at the bottom lets you change it. Note that as of LV6
> these numbers are the maximum limit allocated by LV and it doesn't
> allocate the threads in an execution cell until a VI is loaded that
> needs that system/priority.
>
> Now that I've told you how to do it, I'd recommend doing a very quick
> experiment with the execution system settings to see if there is any
> advantage to having multiple threads active. If the various threads are
> sleeping/waiting for hardware, this may indeed allow other threads to
> make progress, but if they are doing a spin-lock or heavy computation,
> there really isn't any benefit.
>
> Greg McKaskle

Dear Greg,

Thank you for your answer. I checked all the setting and I am sure
that I have these settings correct as you wrote. I tried the VI for
changing allocation of the threads, but the number of threads is too
small for me.

If I am right LV maximum thread number is number of preffered
execution system multiplied available priorities (App.Note 114), what
happened and how in threadconfig.vi is clear for you only (this vi is
locked, by the way number of locked vi's increases with LV version
number 😞 - why this? )

I have from 50 to 200 points with same instrument on every point. So I
need up to 200 parallely running tasks for communicate with these
instruments via DLL based instrument driver, in every parallel task is
unique instrument session, but calling different functions from the
same DLL. Now I am not able to do it in LabView, only way is to use
LabVIEW native driver, but in this case I loose advantages of IVI
driver. Do you have any idea how to use IVI driver in 200 parallel
tasks?

Best regards
Jiri

[JRA]

How are you calling the VIs? Are they linked together in any way which may cause them to run sequentially? Are they all running within one top-level VI? For instance, if their error info lines are connecting them together, this will cause them to run sequentially. Let us know how they're set up with respect to each other and we'll see if we can find something from that.

[Greg_McKaskle2]

> If I am right LV maximum thread number is number of preffered
> execution system multiplied available priorities (App.Note 114), what
> happened and how in threadconfig.vi is clear for you only (this vi is
> locked, by the way number of locked vi's increases with LV version
> number 😞 - why this? )

The number of threads is actually the sum of all the cells, and the
number of cells is execution systems times priorities. As for the
locked VIs, this VI has been locked since LV5.

>
> I have from 50 to 200 points with same instrument on every point. So I
> need up to 200 parallely running tasks for communicate with these
> instruments via DLL based instrument driver, in every parallel task is
> unique instrument session, but calling diff
erent functions from the
> same DLL. Now I am not able to do it in LabView, only way is to use
> LabVIEW native driver, but in this case I loose advantages of IVI
> driver. Do you have any idea how to use IVI driver in 200 parallel
> tasks?

Again, I'd advise you to run a small experiment with two to four threads
or execution systems to see if you get the expected benefits. I find it
very unlikely that you really need 200 threads to make this application
work. If it is indeed the case, I don't know of any limits for the cell
numbers, so you might be able to allocate 200 threads.

In my opinion, this will lead to more OS overhead with multitasking
between the threads, and you will not really get any benefit since you
have a small number of CPUs. Can you explain why you need hundreds of
threads?

Greg McKaskle

[hulaj]

JRA wrote in message news:<5065000000050000004C9C0000-1027480788000@exchange.ni.com>...
> How are you calling the VIs? Are they linked together in any way
> which may cause them to run sequentially? Are they all running within
> one top-level VI? For instance, if their error info lines are
> connecting them together, this will cause them to run sequentially.
> Let us know how they're set up with respect to each other and we'll
> see if we can find something from that.

I have one VI, then I programatically clone it (copy it with new
name), after that I have for example 200 VIs with same code,but
different names. Then I dynamically open and run them. Every VI take
its name (every has unique name), and from the name it takes the
instrument addres
s and with this address it communicates via DLL based
driver. So the code is same for 200 VIs, but instrumnet session is
different. I use IVI driver, and IVI driver is multi-thread safe, but
it calls DLL, which is problem in LabVIEW. I tried this in Visual C++
and I have many parralel threads calling same IVI driver (same DLL)
without any problem, everything works paralell.

[hulaj]

Greg McKaskle wrote in message news:<3D756C10.6010602@austin.rr.com>...
> > If I am right LV maximum thread number is number of preffered
> > execution system multiplied available priorities (App.Note 114), what
> > happened and how in threadconfig.vi is clear for you only (this vi is
> > locked, by the way number of locked vi's increases with LV version
> > number 😞 - why this? )
>
> The number of threads is actually the sum of all the cells, and the
> number of cells is execution systems times priorities. As for the
> locked VIs, this VI has been locked since LV5.
>
> >
> > I have from 50 to 200 points with same instrument on every point. So I
> > need up to 200 parallely running tasks for communicate with these
> > instruments via DLL based instrument driver, in every parallel task is
> > unique instrument session, but calling different functions from the
> > same DLL. Now I am not able to do it in LabView, only way is to use
> > LabVIEW native driver, but in this case I loose advantages of IVI
> > driver. Do you have any idea how to use IVI driver in 200 parallel
> > tasks?
>
> Again, I'd advise you to run a small experiment with two to four threads
> or execution systems to see if you get the expected benefits. I find it
> very unlikely that you really need 200 threads to make this application
> work. If it is indeed the case, I don't know of any limits for the cell
> numbers, so you might be able to allocate 200 threads.
>
> In my opinion, this will lead to more OS overhead with multitasking
> between the threads, and you will not really get any benefit since you
> have a small number of CPUs. Can you explain why you need hundreds of
> threads?
>
> Greg McKaskle

Why I need 200 (or more) paralell tasks ?
Because I am communicating with instruments with different connection
speed(LAN, modem). Or when the one instrument "crashes" (not
communicate), the driver waits to timeout, so if it will be
sequential, all instruments will not communicate at this time. Every
instrument has "Data Ready" in different times, etc.

I need to communicate independently with every instrument.

I tried your example, it makes the running better, but the question
is:
- how can I change these settings in EXE file
- I do not know how many tasks I will need, I do not know how many
instruments there will be, maybe 10, maybe 100 or 300 !!! It depends
on user. So I do not know how to configure the threads before program
starts, and user can add/remove instruments even when program runs !!

Jiri Hula

[Greg_McKaskle2]

> I tried your example, it makes the running better, but the question
> is:
> - how can I change these settings in EXE file
> - I do not know how many tasks I will need, I do not know how many
> instruments there will be, maybe 10, maybe 100 or 300 !!! It depends
> on user. So I do not know how to configure the threads before program
> starts, and user can add/remove instruments even when program runs !!


Backing up a step, you cannot directly control the number of threads.
You cannot create another thread for each and every VI call or DLL node.
If you must do this, then you can call into a DLL to spin up a new
thread, make the driver call, destroy the thread, and return. Perhaps
that is a feature that needs to be added,
but this is the first request
I've heard for it.

You mention that you tried my example. How many threads did you try?
In our experience, a small number of threads will multitask just fine
and you do not normally need to have hundreds of them.

If you need to set the number of threads for an EXE, the settings are
saved to the .ini file. Open the labview.ini file and copy the
execution info and paste it into your "exename".ini file where exename
is your EXE's name.

I hope that this is sufficient. As I said earlier, it is not possible
to manage low level threads as in C/C++, so if that is an absolute
requirement, then you will need to wrap the functions in another DLL call.

Greg McKaskle