> This subVI wrapper worked for me. However, my ActiveX server was
> already an MTA (multithreaded apartment) and that didn't solve the
> problem. It appears that all the code in a VI runs in the one thread
> and that to make your VI multithreaded you have to use subVIs (as
> suggested) which noticably hinders performance. The discussion of
> multithreading in the labview documentation almost suggests that
> multithreading does occur automatically in a single VI without subVIs
> (And maybe it does). It's unfortunate that there isn't a discussion
> of exactly what and how separate threads are trigger to be created.
I'm not sure if I understand the first statement. An MTA server is
part of the solution since it will allow itself to be called from
multiple threads, but that doesn't affect the client -- LV code.
Similarly, you can have as many client threads as you like, but if
the server is STA, it will not matter. Each call will go back to
a single thread and things that access the server will serialize.
So, both things are necessary, the client needs more than one thread
and the server needs to be MTA.
By default, on a single processor computer, a VI diagram runs in one
thread, the thread belonging to the standard execution system, and
the UI runs in the UI thread. Additionally, all of the code that
LV generates will multi-task cooperatively using the standard and
UI execution systems.
You can make sure that the ActiveX calls run in a different execution
system by wrapping them in a subVI. Yes, a subVI does add a small
amount of overhead, but assuming the subVI panel isn't open, the amount
is quite small, especially when compared to the overhead that COM and
data conversions can add. Of course if you are going to make millions
of calls to the subVI, this will add up, and it is usually quite easy to
move some of the looping code down into the subVI call as well to reduce
the number of subVI calls drastically.
There is a second technique for making additional threads available,
it involves changing the .ini file to make an execution system have
additional threads. A dual processor machine automatically allocates
two threads instead of one. You can set this to any amount you like,
but it is pretty rare that this is needed.
One last piece of info. The goal of the LV execution system is to avoid
allocating lots of OS threads. It takes quite a bit of time for the OS
to allocate or destroy a thread. Similarly, it takes quite a bit of time
for the OS to stop one thread, swap in another, and swap back, so LV tries
to avoid this as well. LV does lots of multi-tasking, it always has, even
on single threaded OSes. LV tries to balance efficient operation with
parallel execution, and it allows for several ways of controlling this.
If you have other questions, fire away.
Greg McKaskle