ActiveX Dll: Should it be multi-threaded? 
Author Message
 ActiveX Dll: Should it be multi-threaded?

I have an ActiveX Dll product, and a client has asked if I could make
it multi-threaded.  Before I start digging in to learn all the issues
involved, I'm wondering if it's a bad idea for my product.

Here's the issue:  on startup, the major processing chore is reading a
big data file and constructing an object collection from it.
Calculations from that point are efficient.

Won't multiple threads cause lots of creation and deletion of my
ActiveX Dll, and therefore cause lots of this slow initializing?  Or
is there a way to have multiple threads share the initialized object
collection?

Wayne



Sat, 10 Mar 2001 03:00:00 GMT  
 ActiveX Dll: Should it be multi-threaded?
Hi,

if you're collection is a global multiuse class, it will be initialized only
one time (not exactly but this is another story....)

--
FlyKiller
If you liked my answer, sign my Guestbook!
HomePage: http://home.tvd.be/ws36009
ICQ: 6351237


Quote:
>I have an ActiveX Dll product, and a client has asked if I could make
>it multi-threaded.  Before I start digging in to learn all the issues
>involved, I'm wondering if it's a bad idea for my product.

>Here's the issue:  on startup, the major processing chore is reading a
>big data file and constructing an object collection from it.
>Calculations from that point are efficient.

>Won't multiple threads cause lots of creation and deletion of my
>ActiveX Dll, and therefore cause lots of this slow initializing?  Or
>is there a way to have multiple threads share the initialized object
>collection?

>Wayne



Sat, 10 Mar 2001 03:00:00 GMT  
 ActiveX Dll: Should it be multi-threaded?
Wayne,

Since an ActiveX DLL created by VB can't actually create threads (only its
'container' can), the issue is really whether or not the container can
treat the ActiveX DLL as multi-threaded or not.

In short, with VB ActiveX DLLs, always set it to apartment model threading.

Matthew



Quote:
> I have an ActiveX Dll product, and a client has asked if I could make
> it multi-threaded.  Before I start digging in to learn all the issues
> involved, I'm wondering if it's a bad idea for my product.

> Here's the issue:  on startup, the major processing chore is reading a
> big data file and constructing an object collection from it.
> Calculations from that point are efficient.

> Won't multiple threads cause lots of creation and deletion of my
> ActiveX Dll, and therefore cause lots of this slow initializing?  Or
> is there a way to have multiple threads share the initialized object
> collection?

> Wayne



Sat, 10 Mar 2001 03:00:00 GMT  
 ActiveX Dll: Should it be multi-threaded?
I don't really understand the issues here yet.  What I've seen so far
is that removing all UI elements will allow me to mark the Dll for
"unattended execution", and it seems this is related to the threading
model.  The client who requested this change is considering a
multi-threaded application, and is asking if I can make the Dll
multi-threaded for performance reasons.

What I'm looking for at this point is some general direction.  Will it
be worth the effort for me to dig in and learn about threading?  How
difficult will it be for me to set up the object collection (which is
read-only by the way)  as a "Global Multiuse" class which gets shared
by all the threads?  Are there some pitfalls to watch out for?

Thanks for your help.

Wayne
On 22 Sep 1998 23:28:23 GMT, "Matthew Wills"

Quote:

>Wayne,

>Since an ActiveX DLL created by VB can't actually create threads (only its
>'container' can), the issue is really whether or not the container can
>treat the ActiveX DLL as multi-threaded or not.

>In short, with VB ActiveX DLLs, always set it to apartment model threading.

>Matthew



>> I have an ActiveX Dll product, and a client has asked if I could make
>> it multi-threaded.  Before I start digging in to learn all the issues
>> involved, I'm wondering if it's a bad idea for my product.

>> Here's the issue:  on startup, the major processing chore is reading a
>> big data file and constructing an object collection from it.
>> Calculations from that point are efficient.

>> Won't multiple threads cause lots of creation and deletion of my
>> ActiveX Dll, and therefore cause lots of this slow initializing?  Or
>> is there a way to have multiple threads share the initialized object
>> collection?

>> Wayne



Sun, 11 Mar 2001 03:00:00 GMT  
 ActiveX Dll: Should it be multi-threaded?
There are several different flavors of multi-threading. VB supports
several varieties of "apartment" threading. For instance, in a VB
component set to multi-use and thread-per-object, each thread in the
component will have its own apartment. Which means, each thread will
have its own copy of _global_ and local data: it is entirely unaware of
and unaffected by other threads running in that component.

Sharing data between threads in VB is not particularly easy. It
certainly isn't what was intended by VB's threading model.

A tack you might want to consider is asking yourself "What is the client
really looking for?" Does the client have some particular interest in
how many threads your component has? Or does he just want it to load
faster and thinks the more threads the better?

If it's the latter, then threading might not be your only option. For
instance, does all the data _have_ to be loaded _before_ the component
can begin to function? Or can you rewrite it so it only loads data on
demand?

Or, can you initially load enough data to get the component initialized
and then use a timer to drive a state machine to finish loading data in
the background?

I've used the first technique with a fair amount of success. It
dramatically reduces the time it takes to initialize the component, and
usually the process of loading additional data on demand is so fast
(because you're just dealing with small chunks), that the user won't
even be conscious that's what's going on. And after the data has been
loaded once, there's no further performance hit.

Quote:

> I have an ActiveX Dll product, and a client has asked if I could make
> it multi-threaded.  Before I start digging in to learn all the issues
> involved, I'm wondering if it's a bad idea for my product.

> Here's the issue:  on startup, the major processing chore is reading a
> big data file and constructing an object collection from it.
> Calculations from that point are efficient.

> Won't multiple threads cause lots of creation and deletion of my
> ActiveX Dll, and therefore cause lots of this slow initializing?  Or
> is there a way to have multiple threads share the initialized object
> collection?

> Wayne

--
"I know.
Once I escaped to Tangier..."


Sun, 11 Mar 2001 03:00:00 GMT  
 ActiveX Dll: Should it be multi-threaded?
Joel,

Thanks for the response.  I've looked into this approach before, but
it's just not practical with this data.  

You did get me thinking about another approach, however.  What if I
suggest that the application (which calls my Dll) initialize a pool of
threads?  Does this mean that each apartment will be initialized once,
then used over & over without having to be reinitialized? That way,
the app takes a big performance hit only at startup.

Wayne

On Wed, 23 Sep 1998 09:59:04 -0700, Joel Shepherd

Quote:

>There are several different flavors of multi-threading. VB supports
>several varieties of "apartment" threading. For instance, in a VB
>component set to multi-use and thread-per-object, each thread in the
>component will have its own apartment. Which means, each thread will
>have its own copy of _global_ and local data: it is entirely unaware of
>and unaffected by other threads running in that component.

>Sharing data between threads in VB is not particularly easy. It
>certainly isn't what was intended by VB's threading model.

>A tack you might want to consider is asking yourself "What is the client
>really looking for?" Does the client have some particular interest in
>how many threads your component has? Or does he just want it to load
>faster and thinks the more threads the better?

>If it's the latter, then threading might not be your only option. For
>instance, does all the data _have_ to be loaded _before_ the component
>can begin to function? Or can you rewrite it so it only loads data on
>demand?

>Or, can you initially load enough data to get the component initialized
>and then use a timer to drive a state machine to finish loading data in
>the background?

>I've used the first technique with a fair amount of success. It
>dramatically reduces the time it takes to initialize the component, and
>usually the process of loading additional data on demand is so fast
>(because you're just dealing with small chunks), that the user won't
>even be conscious that's what's going on. And after the data has been
>loaded once, there's no further performance hit.


>> I have an ActiveX Dll product, and a client has asked if I could make
>> it multi-threaded.  Before I start digging in to learn all the issues
>> involved, I'm wondering if it's a bad idea for my product.

>> Here's the issue:  on startup, the major processing chore is reading a
>> big data file and constructing an object collection from it.
>> Calculations from that point are efficient.

>> Won't multiple threads cause lots of creation and deletion of my
>> ActiveX Dll, and therefore cause lots of this slow initializing?  Or
>> is there a way to have multiple threads share the initialized object
>> collection?

>> Wayne

>--
>"I know.
>Once I escaped to Tangier..."



Tue, 13 Mar 2001 03:00:00 GMT  
 ActiveX Dll: Should it be multi-threaded?
If you benefit from keeping the threads available after the application
has started, this might be a solution. Basically, you'd need to write a
"thread manager" to create and hold on to (keep alive) a pool of threads
(i.e., creatable objects) and then pass back references to those threads
(objects) as your application requests them.

There have been a couple articles in Visual Basic Programmers Journal
(Feb. 98 for one) about this, and the sample code is probably still
available at www.windx.com .

Quote:

> Joel,

> Thanks for the response.  I've looked into this approach before, but
> it's just not practical with this data.

> You did get me thinking about another approach, however.  What if I
> suggest that the application (which calls my Dll) initialize a pool of
> threads?  Does this mean that each apartment will be initialized once,
> then used over & over without having to be reinitialized? That way,
> the app takes a big performance hit only at startup.

> Wayne

<trimmed>

--
I know
Once I escaped to Tangier...



Tue, 13 Mar 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. ActiveX Multi-threaded dll

2. vb6 activex ocx components used in multi-threaded client application

3. Multi-threaded ActiveX control

4. Multi-threading via ActiveX

5. multi-threaded access to VB ActiveX EXE

6. Multi-threaded ActiveX control

7. Multi loop threading with emon32.dll

8. VB as a client of a multi-threaded DLL

9. Multi-processor/ Multi-thread programming

10. Threading and Unattended Activex Dll

11. GURU/SEMI-GURU please help with ActiveX DLL threading question

12. ActiveX DLL and ASP - What am I missing?

 

 
Powered by phpBB® Forum Software