Is a VI Server a MTA ot a STA

[ChuckS]

I cant seem to find the answer. My guess is the ActiveX VI Server is a Single Thread Apartment.

I am new to the specifics of threads.

But the question still remains, Is the VI server a Multithread Apartment or a Single Thread Apartment.

Because a VI can only handle on call at a time, my guess is Single.

I am having problems with "Call by Reference" which is passing alot of info. I believe that because  "Call by Reference" calls the " Vi Server" via activeX this operation is done in the UI thread. When the call to the remote VI occurs the UI thread (STA?) is held up along with the "system execution thread(MTA?) because it is a Vi that wait till all is done" . This prevents my code from executing, so I think.

Comments?

Chuck

[Ben]

It took me a lot of work to get a definative answer to that Q.

Yes, VI server executes in the UI thread.

Not nessessarily the whole VI but when the times comes to do the VI server thing, that work is performed in the UI thread.

Ben

[ChuckS]

Hi Greg,

I was wondering if you have time to answer one question in the NI discussion forums.

You have an understanding of this subject and I need to understand it.

http://forums.ni.com/ni/board/message?board.id=170&message.id=151543

Basically what all happens when a dynamic call is made. Is the client in the UI thread, Is the server in the UI thread.

Is the client a STA or an MTA. Is the server a STA or an MTA. If there is a hold up are the messages held up in the

Windows message queue ?

Lastly, How do you get around a backup in the queue?

Thanks Much

Chuck Streb

[Dennis_Knutson]

Could you explain the reason for your question? Are you having some specific problem with Call by Reference? It sounds like you might be expecting that the main VI to continue to run before the subVI finishes and returns. That is not how it works. You can use an Invoke Node with the method Run VI or put your Call by Reference in a separate while loop.

[ChuckS]

>Could you explain the reason for your question? Are you having some specific problem with Call by Reference? It sounds like you might be >expecting that the main VI to continue to run before the subVI finishes and returns. That is not how it works. You can use an Invoke Node with >the method Run VI or put your Call by Reference in a separate while loop.

I need to get a better understanding of what is going on so that I may write better code.

We are using activeX and dynamic calls extensively.

I would like to know exactly what is going on so that I may take advantage of what I learn.

For example, can you explain why Call by Reference in a separate while loop works. I still think it holds up the UI thread both in the client and in the server.

Greg understands this exactly. It would be nice to have a posting so that all can see !

[Greg_McKaskle2]

I wouldn't say I understand this exactly because I don't have much background on what action is being performed.

Here is some background.

The VI server is executed largely within the UI thread -- reason is that since some things need to be synchronized and protected, this acts as the primary gateway. Many of the operations will move to other threads once they pass through the VI Server gateway.

If you are using a Call by Reference node from a LV diagram to call a local VI, ActiveX is not involved unless some of the datatypes are ActiveX variants. The diagram containing the Call by Ref node could be running in any thread. And in fact, many diagrams could be requesting that the subVI be executed -- some of those diagrams can even be from other computers. So, the call is posted to the UI thread so that the VI server can pick the first one to call the subVI. The parameters are copied into the subVI, and the subVI is scheduled to run wherever it likes -- not necessarily in the UI thread. This may free the UI thread up to do other things. If the execution is in the UI thread, then the UI thread will cooperatively schedule the code of the subVI with all of the other things it has to do, like drawing and servicing other VI Server requests.

As mentioned by others, the diagram that contains the node cannot complete. Other code within it might run in parallel if it is not dataflow dependent, but sooner or later, the code will sleep waiting for the subVI to complete and for the UI thread to copy the parameters back.The blocking behavior of the caller isn't affected by what threads the caller or subVI are executed in. It is an intentional synchronization feature.  If you do not need to wait or do not want to wait for completion, then the invoke node with the Run method is what you want to look into.

You mentioned that you are also using ActiveX services. Just a caution, while it will work, using LV services via ActiveX within LV itself is not such a wise thing to do. So presumeably you are using ActiveX to affect other apps and servers and using the VI Server nodes to affect LV itself.

ActiveX services within LV support MTA if the server does. If MTA, any thread can go into the server and the server will provide its own protection, which can still block threads. If it is STA, then LV is responsible for the protection and it will do so by posting to the thread that loaded the server. In quite a few cases this turns out to be the UI thread.

So, I doubt that this background info is really that useful, so to go further, I think you will need to describe the exact task you are trying to carry out, what seems to be going wrong, what problems you see, alternatives you have tried, etc.

Greg McKaskle

[Dennis_Knutson]

Welcome back, Greg!

[ChuckS]

Greg,

Thanks for getting back to me!

I looked into the code again.

What we do is execute our Vi's in a tree form. Level 1 VI's executes Level 2 Vi's via VI server. Level 2 VI's  executes Level 3 VI's  via VI server ... etc until all of our components are executed. Then we loop back and do it again.

Because we use action engine type Vis (many methods in one Vi, selected by an enum), we are able to call these same Vi's from our Views for information. Not all the information is used. In some cases the information being past via the VI server is large and not used. Only because of the wrapper structure (vi server).

We also use "invoke node" to read and write information(values)  to our Views controls and indicators. This is separate from above.

But it is apart of whats going on.

We have ran into the limit of what is past through the VI server. We have gotten to the point where the computer doesn't have enough to keep up.

So we limited the amount of information that was being passed through the VI server calls. This seems to have fixed things for now.

This is the structure and I am looking to improve it before we see the next wall that comes our way! 

We have very large projects built on this technology. More than 1000+ sub Vi's in an app.

If you have any idea's for improvement, it would be appreciated.

Thanks Much Greg

Chuck

[ChuckS]

Ohh and I forgot to say, All Vi's are in the "same as caller" execution thread.

[Greg_McKaskle2]

You don't mention why it is that the VI Server is what is used for all the calls. Is is because the relationship isn't known until runtime?
The overhead for making a subVI call through the VI server is quite a bit larger. For a small subVI, it might be hundreds of times more expensive, and to pass data, CBR (Call by Ref) is never inplace. It will always copy data into and out of the subVI. So large amounts of data can quickly take lots of extra space and time to do copies.
I've seen architectures a bit like this in the past, but they were done this way so that the calls could be rearranged at runtime into a different order, or to skip some of them. The subVIs were passed little or no actual data, but were instead given references to do data lookups as needed.
So, what was the original reason for not using normal subVI calls, are the reasons still valid, are the large numbers needed? When you talk about reaching a limit, what is the type and size of data, and how many calls are we talking about per second?
I know that I'm asking questions rather than answering, but at this stage, I think a good question is better than a lame answer.

Greg McKaskle