Is dll threading treated the same as vi threading? 
Author Message
 Is dll threading treated the same as vi threading?

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...



Sat, 25 Jun 2005 00:27:28 GMT  
 Is dll threading treated the same as vi threading?
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



Sat, 25 Jun 2005 02:59:28 GMT  
 Is dll threading treated the same as vi threading?
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 that
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



Sun, 26 Jun 2005 04:13:03 GMT  
 Is dll threading treated the same as vi threading?
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



Sun, 26 Jun 2005 04:53:06 GMT  
 Is dll threading treated the same as vi threading?
My info is marked with ***s.

Quote:
> 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.

Quote:
> 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



Sun, 26 Jun 2005 12:15:17 GMT  
 Is dll threading treated the same as vi threading?
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



Mon, 27 Jun 2005 01:36:10 GMT  
 Is dll threading treated the same as vi threading?
Oops,

I guess it didn't get posted.

I'll try again,
Eric



Mon, 27 Jun 2005 01:42:20 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Threads creating threads creating threads...

2. thread, threading, mutex modules and non-threading interpreters

3. Non-threaded function in a threaded recursion?

4. Thread.new vs. Thread.start

5. Thread#kill doesn't kill processes inside a thread

6. meditations on threads and thread safety

7. Tkinter and thread (or thread and Tkinter...)

8. threading.Thread.join(timeout=...) considered unreliable

9. Cygwin Python -- Thread or not to thread...

10. Threads in Python version 1.5, thread doesn't start until calling process dies

11. pydoc req thread; readline req NO thread

12. Threaded server doesn't run its threads

 

 
Powered by phpBB® Forum Software