Is dll threading treated the same as vi threading?

[Eric6756]

I noticed by default my dll built by Visual C++ is set to run in the gui interface subsystem which I assume is equivalent to labview's gui interface thread. Yes?

I further assume that calling into the dll from any vi running in any thread is equivalent to calling a subroutine vi set to run in the gui interface thread. Yes?

If yes and yes, and since labview cannot suspend a subroutine vi or the dll, the gui interface thread would be 100% utilized by the call. It would therefore seem, that all other operations occurring in the gui interface thread would be suspended until the call completes, and further more if the dll call is made through a subroutine sub-vi set to run in the caller's thread, then the caller's
thread would also be suspended. Yes?

Hence, you could weave yourself into a situation where all other threads are awaiting the execution of gui interface thread. And that then leads to the question of the order in which execution will occur once qued.

Typically, my threading is separated in my top level vis and the lower level vis are set to run in the caller's thread. But in migrating from LV4.x to LV6i, I never checked my API call dlls execution subsystems, which if the above is correct, may adversely affect my presumed threading...

So... Assuming the above is true and to avoid it, can I create a dll that runs in the caller's thread, or must the dll's execution thread be specifically set when it is built? More generally, is there a way to avoid this short of insuring that the threads do not compete for the same code resources?


Thanks,
Kind Regards,
Eric


PS: it might be kinda nice to see the threading identifiable (connections highlighted in various colors
for example) in the vi hierarchy window...

[Ben]

Hi Eric,

As I understand,

Yes, yes, yes, yes, ....

If your .dll is thread-safe, it is possible to configure it as such (in configure dialog box there is a drop down that says run in UI thread, change it). This will change the icon from orange to yellow.

After that the .dll will run in what ever thread it was called from.

Ben

[Eric6756]

Thanks Ben,

If understand things correctly the following should be true:

Assuming I specify all dll calls as re-entrant, the number of simultaneous dll calls that can be made from within labVIEW is limited to the number of threads. Specifically, once the dll has control of the thread, nothing else in labVIEW can execute in that thread until the dll call completes. Yes?

And if that is true then this should also be true:

If a thread ID were attached to information passed to a labVIEW library function, and that function retained the information for labVIEW, then labVIEW in theory could request the information from the function when the dll call completed. The thread Id would uniguely identify the data because only one dll call can be made with t
hat thread from within labVIEW and of course labVIEW knows which thread is making the call. Yes?

You may think this is a bit obtuse, but this line of questions was provoked by a statement made else where about dlls that left me a bit perplexed.

Kind Regards,
Eric

[Ben]

Hi Eric,

After reading your follow-up, I went into cerebral over-load.

My first instinct is that if your dll is re-entrant, it should not lock-up any thread.

Could you please post this follow-up question to the list as a new Q? Iwould love to hear others (maybe Greg McKaskle) adress this follow-up.

Ben

[Greg_McKaskle2]

My info is marked with ***s.


> Assuming I specify all dll calls as re-entrant, the number of
> simultaneous dll calls that can be made from within labVIEW is limited
> to the number of threads. Specifically, once the dll has control of
> the thread, nothing else in labVIEW can execute in that thread until
> the dll call completes. Yes?
>

A DLL doesn't normally multitask with other code, but there are
situations where it does, such as when the DLL decides to process or
pump messages. The above assumption is pretty accurate, but there are
things a DLL could do that would void them.

> If a thread ID were attached to information passed to a labVIEW
> library function, and that function retained the information for
> labVIEW, then labVIEW in theory could request the information from the
> function when the dll call completed. The thread Id would uniguely
> identify the data because only one dll call can be made with that
> thread from within labVIEW and of course labVIEW knows which thread is
> making the call. Yes?
>

I'm not sure I understand where this is going. Any DLL is free to pay
attention to the thread ID, but there is no guarantee that the same
thread will be used for the VI's next execution, or for the DLL's next
execution. Information can be stored by the DLL using the threadID, but
LV doesn't know anything about the information or even which thread
executed the DLL once it returns.

Perhaps this info will help out. LV has two ways of executing a DLL
call. If the DLL call is marked as reentrant, then it will be called in
the current thread. It is then the DLL's responsibility to protect any
data or code section that cannot have multiple threads in it simultaneously.

For compatibility, and to make it easy to protect a DLL call, you can
mark it as non-reentrant. This will cause the DLL to be swapped over to
the UI thread so that any other thread trying to call the code at the
same time will be blocked, and the DLL call will be protected.

If you have other questions, ask them.
Greg McKaskle

[Eric6756]

Greg,

I did as Ben asked and reposted at the top. Hopefully, the discussion I provide there will be more illuminating. The reply to this will be posted there.

Thanks,
Eric

[Eric6756]

Oops,

I guess it didn't get posted.

I'll try again,
Eric