MultiThreading an ActiveX DLL call...

[Cybertof]

Hello,

Is there a good way to call a big time-consumming function from an
ActiveX DLL (interoped) through a thread without blocking the main UI ?

Here are the details :

I have a class CInteropCall encapsulating a call to a visual basic
ActiveX DLL function named FillAlloc_Array Struct_Double() , which is
allocating a big struct array an fills it using a inner loop
(for i = 1 to 300000...)

I'm calling this BigProcess through a thread from the main UI
like this :

CInteropCall MyThreadProcess = new CInteropCall();
Thread m_WorkerThread;
m_WorkerThread = new Thread(new ThreadStart(MyT hreadProcess.Te stMe));
m_WorkerThread. IsBackground = true;
m_WorkerThread. Name = "ThreadLow" ;
m_WorkerThread. Priority = System.Threadin g.ThreadPriorit y.Lowest;
m_WorkerThread. Start();


Here is the TestMe() method from the CInteropCall class which is calling
the function through an instance of a VB6 Class :
public void TestMe()
{
AX_DLL.FillAllo c_ArrayStruct_D ouble(3000000, ref array_struct_do uble);
}


The problem is :
The main UI is blocked when starting the thread, and from time to time
during the thread execution.

Solutions tested :
- adding a Sleep(1) in the inner loop of the vb6 function
It does not change a lot
- adding a DoEvents() in the vb6 function
It does not change a lot but slows down the thread execution.


The same big loop executing from a c# function does not block the main
UI (even without sleep(1)...), the UI remains very smooth.


Any idea to make an interoped vb6 activex call 'UI thread friendly' ?
(or maybe there is no way to do it...)



Regards,
Cybertof.

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cd874 49b18e00bf98968 e@news.wanadoo. fr...[color=blue]
> Hello,
>
> Is there a good way to call a big time-consumming function from an
> ActiveX DLL (interoped) through a thread without blocking the main UI ?
>
> Here are the details :
>
> I have a class CInteropCall encapsulating a call to a visual basic
> ActiveX DLL function named FillAlloc_Array Struct_Double() , which is
> allocating a big struct array an fills it using a inner loop
> (for i = 1 to 300000...)
>
> I'm calling this BigProcess through a thread from the main UI
> like this :
>
> CInteropCall MyThreadProcess = new CInteropCall();
> Thread m_WorkerThread;
> m_WorkerThread = new Thread(new ThreadStart(MyT hreadProcess.Te stMe));
> m_WorkerThread. IsBackground = true;
> m_WorkerThread. Name = "ThreadLow" ;
> m_WorkerThread. Priority = System.Threadin g.ThreadPriorit y.Lowest;
> m_WorkerThread. Start();
>
>
> Here is the TestMe() method from the CInteropCall class which is calling
> the function through an instance of a VB6 Class :
> public void TestMe()
> {
> AX_DLL.FillAllo c_ArrayStruct_D ouble(3000000, ref array_struct_do uble);
> }
>
>
> The problem is :
> The main UI is blocked when starting the thread, and from time to time
> during the thread execution.
>
> Solutions tested :
> - adding a Sleep(1) in the inner loop of the vb6 function
> It does not change a lot
> - adding a DoEvents() in the vb6 function
> It does not change a lot but slows down the thread execution.
>
>
> The same big loop executing from a c# function does not block the main
> UI (even without sleep(1)...), the UI remains very smooth.
>
>
> Any idea to make an interoped vb6 activex call 'UI thread friendly' ?
> (or maybe there is no way to do it...)
>
>
>
> Regards,
> Cybertof.[/color]

You should initialize your (m_WorkerThread ) thread to enter an STA. The way
you do it now results in your COM object to run on the main UI thread.

...
m_WorkerThread. ApartmentState = ApartmentState. STA;
m_WorkerThread. Start();
....

Willy.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

In article <ejWC2nnSFHA.72 0@TK2MSFTNGP10. phx.gbl>,
willy.denoyette @telenet.be says...[color=blue]
>[/color]
[color=blue]
> You should initialize your (m_WorkerThread ) thread to enter an STA. The way
> you do it now results in your COM object to run on the main UI thread.[/color]
[color=blue]
> ..
> m_WorkerThread. ApartmentState = ApartmentState. STA;
> m_WorkerThread. Start();
> ...[/color]


Hi Willy,

That's exactly what I do not want...
I want the thread no to disturb the main UI thread at all.


Cybertof.

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cd892 bf4e4e231198969 0@news.wanadoo. fr...[color=blue]
> In article <ejWC2nnSFHA.72 0@TK2MSFTNGP10. phx.gbl>,
> willy.denoyette @telenet.be says...[color=green]
>>[/color]
>[/color]
[color=blue]
> I want the thread no to disturb the main UI thread at all.[/color]


Sure, but YOU DO disturb the UI by NOT initializing the background thread to
enter an STA, note this is not the UI thread's apartment but a newly created
apartment.
If you don't initialize your backround thread to enter an STA, the AX object
will enter the UI thread's apartment and calls to methods on this object
will run on the UI thread.

Hope it's clear now.

Willy.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

In article <uKuy0vqSFHA.14 04@TK2MSFTNGP09 .phx.gbl>,
willy.denoyette @telenet.be says...[color=blue]
>
> Sure, but YOU DO disturb the UI by NOT initializing the background thread to
> enter an STA, note this is not the UI thread's apartment but a newly created
> apartment.
> If you don't initialize your backround thread to enter an STA, the AX object
> will enter the UI thread's apartment and calls to methods on this object
> will run on the UI thread.
>
> Hope it's clear now.
>
> Willy.
>
>[/color]

Thanks, it's more clear.

And should the VB6 ActiveX be compiled with
'Single Threaded' or 'Apartment Threaded' ?


Regards,
Cybertof.

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cd94c c3b4c0904098969 1@news.wanadoo. fr...[color=blue]
> In article <uKuy0vqSFHA.14 04@TK2MSFTNGP09 .phx.gbl>,
> willy.denoyette @telenet.be says...[color=green]
>>
>> Sure, but YOU DO disturb the UI by NOT initializing the background thread
>> to
>> enter an STA, note this is not the UI thread's apartment but a newly
>> created
>> apartment.
>> If you don't initialize your backround thread to enter an STA, the AX
>> object
>> will enter the UI thread's apartment and calls to methods on this object
>> will run on the UI thread.
>>
>> Hope it's clear now.
>>
>> Willy.
>>
>>[/color]
>
> Thanks, it's more clear.
>
> And should the VB6 ActiveX be compiled with
> 'Single Threaded' or 'Apartment Threaded' ?
>
>
> Regards,
> Cybertof.[/color]

Apartment.

Willy.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

In article <#ELS98vSFHA.62 8@tk2msftngp13. phx.gbl>,
willy.denoyette @telenet.be says...[color=blue]
>
> "Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
> news:MPG.1cd94c c3b4c0904098969 1@news.wanadoo. fr...[color=green]
> > In article <uKuy0vqSFHA.14 04@TK2MSFTNGP09 .phx.gbl>,
> > willy.denoyette @telenet.be says...[/color]
>
> Apartment.
>
> Willy.
>
>
>[/color]

STA...Appartmen t...no changes.

I think it's not a problem of thread :

A very very long time is spent during parameter passing.

My array is passe byref, I don't understand why it takes so long time.


Is there any method to pass efficiently an array as a parm to a VB6
ActiveX DLL function ?


Regards,
Cybertof.

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cd985 a3c2ba87a898969 3@news.wanadoo. fr...[color=blue]
> In article <#ELS98vSFHA.62 8@tk2msftngp13. phx.gbl>,
> willy.denoyette @telenet.be says...[color=green]
>>
>> "Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
>> news:MPG.1cd94c c3b4c0904098969 1@news.wanadoo. fr...[color=darkred]
>> > In article <uKuy0vqSFHA.14 04@TK2MSFTNGP09 .phx.gbl>,
>> > willy.denoyette @telenet.be says...[/color]
>>
>> Apartment.
>>
>> Willy.
>>
>>
>>[/color]
>
> STA...Appartmen t...no changes.
>
> I think it's not a problem of thread :
>
> A very very long time is spent during parameter passing.
>
> My array is passe byref, I don't understand why it takes so long time.
>
>
> Is there any method to pass efficiently an array as a parm to a VB6
> ActiveX DLL function ?
>
>
> Regards,
> Cybertof.[/color]

Are you sure that you create the instance of your COM object, and call the
COM method in the same thread procedure?
Failing to do so will incur thread marshaling overhead!

So the STA threading rules are simple;
- initialize your thread to enter an STA.
- call the COM object's methods on the same thread as the one that created
the object instance.

Willy.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

In article <ukla02ySFHA.36 36@TK2MSFTNGP14 .phx.gbl>,
willy.denoyette @telenet.be says...
[color=blue]
> Are you sure that you create the instance of your COM object, and call the
> COM method in the same thread procedure?
> Failing to do so will incur thread marshaling overhead!
>
> So the STA threading rules are simple;
> - initialize your thread to enter an STA.
> - call the COM object's methods on the same thread as the one that created
> the object instance.
>
> Willy.
>[/color]

Yes, I'm sure, everything is done in the same thread.

As another example, I have removed the 2nd thread creation, and made the
call directly behing a button_click in the main UI Thread.

It's slow when passing the array to the VB6 AX Function, and returning
from the function.

It seems like the array is entirely copied instead of beeing passed
byref. (even if the ref keyword is used during the call...)


Any idea ?

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cd9d2 ace4664aa398969 4@news.wanadoo. fr...[color=blue]
> In article <ukla02ySFHA.36 36@TK2MSFTNGP14 .phx.gbl>,
> willy.denoyette @telenet.be says...
>[color=green]
>> Are you sure that you create the instance of your COM object, and call
>> the
>> COM method in the same thread procedure?
>> Failing to do so will incur thread marshaling overhead!
>>
>> So the STA threading rules are simple;
>> - initialize your thread to enter an STA.
>> - call the COM object's methods on the same thread as the one that
>> created
>> the object instance.
>>
>> Willy.
>>[/color]
>
> Yes, I'm sure, everything is done in the same thread.
>
> As another example, I have removed the 2nd thread creation, and made the
> call directly behing a button_click in the main UI Thread.
>
> It's slow when passing the array to the VB6 AX Function, and returning
> from the function.
>
> It seems like the array is entirely copied instead of beeing passed
> byref. (even if the ref keyword is used during the call...)
>
>
> Any idea ?
>
>[/color]


Ok, don't mix two different issues, speed and UI responsiveness. Your
initial issue was that the UI thread was blocked for the duration of the
call, the solution for this was to move this to a background thread, right?
Well, is this issue solved?
If it is, we can have a look at the speed issue, a few questions come to
mind though, how's the speed compared to a VB6 client calling into your
object? Could you post some code?

Willy.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

In article <OY#PrX0SFHA.10 40@TK2MSFTNGP10 .phx.gbl>,
willy.denoyette @telenet.be says...[color=blue]
>
> "Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
> news:MPG.1cd9d2 ace4664aa398969 4@news.wanadoo. fr...[color=green]
> > In article <ukla02ySFHA.36 36@TK2MSFTNGP14 .phx.gbl>,
> > willy.denoyette @telenet.be says...[/color][/color]
[color=blue]
> Ok, don't mix two different issues, speed and UI responsiveness. Your
> initial issue was that the UI thread was blocked for the duration of the
> call, the solution for this was to move this to a background thread, right?
> Well, is this issue solved?
> If it is, we can have a look at the speed issue, a few questions come to
> mind though, how's the speed compared to a VB6 client calling into your
> object? Could you post some code?
>
> Willy.
>[/color]

Well, the first issue is not totally solved :
Moving the call within a background thread (STA or not) gives more
responsive to the UI, but still blocks it from time to time, which does
occur only at all with the call to the ActiveX DLL Method, so I supposed
there is a thread problem with big arrays beeing passed to an ActiveX,
even if the background thread instanciates the ActiveX Class and calls
it from there.

Let's try to solve the 'Speed problem first' (easier as no background
thread is involved).

Here is some code :

*************** ****
VB6 ACTIVEX DLL : (in a Class named CTest)
*************** ****
Type VBStruct
d As Date
e As Integer
o As Double
h As Double
l As Double
c As Double
v As Long
oi As Long
End Type

Public Sub TestCall(ByRef data() As VBStruct)
MsgBox "FillArrayStruc t_Double : INSIDE AX CALL" // L4
End Sub


*************** *******
C# Test Application : (AX_DLL is the namespace viewed from c#)
*************** *******
AX_DLL.CTest MyTest; // Active X DLL
AX_DLL.VBStruct[] array_struct = null;
MyTest = new AX_DLL.CTest();
startTime = DateTime.Now.Ti cks;
MessageBox.Show ("before alloc...");
array_struct = new AX_DLL.VBStruct[3000000]; // L1
MessageBox.Show ("before ax call"); // L2
AX_DLL.TestCall (ref array_struct_do uble); // L3
MessageBox.Show ("after ax call"); // L5




With this code, 'L1' is immediate to execute,
but, it takes quite some long time to go from
L2->L3->L4, and same long time to go through
L4->L5.

If you replace L1 with
array_struct = new AX_DLL.VBStruct[10]; // L1
everything gets very fast, no wait between calls...

The only cause of the slowness is passing a big array as a parameter.

Do you have an idea ?

Regarding the thread issue, if I put all the C# code above inside a
background STA Thread, the main UI stills blocks approximatively at the
same lines...


Regards,
Cybertof.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

Code Update (L3 was wrong)

Please replace

AX_DLL.TestCall (ref array_struct_do uble); // L3

with

MyTest.TestCall (ref array_struct_do uble); // L3

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cd9ec db527cd76989695 @news.wanadoo.f r...[color=blue]
> In article <OY#PrX0SFHA.10 40@TK2MSFTNGP10 .phx.gbl>,
> willy.denoyette @telenet.be says...[color=green]
>>
>> "Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
>> news:MPG.1cd9d2 ace4664aa398969 4@news.wanadoo. fr...[color=darkred]
>> > In article <ukla02ySFHA.36 36@TK2MSFTNGP14 .phx.gbl>,
>> > willy.denoyette @telenet.be says...[/color][/color]
>[color=green]
>> Ok, don't mix two different issues, speed and UI responsiveness. Your
>> initial issue was that the UI thread was blocked for the duration of the
>> call, the solution for this was to move this to a background thread,
>> right?
>> Well, is this issue solved?
>> If it is, we can have a look at the speed issue, a few questions come to
>> mind though, how's the speed compared to a VB6 client calling into your
>> object? Could you post some code?
>>
>> Willy.
>>[/color]
>
> Well, the first issue is not totally solved :
> Moving the call within a background thread (STA or not) gives more
> responsive to the UI, but still blocks it from time to time, which does
> occur only at all with the call to the ActiveX DLL Method, so I supposed
> there is a thread problem with big arrays beeing passed to an ActiveX,
> even if the background thread instanciates the ActiveX Class and calls
> it from there.
>
> Let's try to solve the 'Speed problem first' (easier as no background
> thread is involved).
>
> Here is some code :
>
> *************** ****
> VB6 ACTIVEX DLL : (in a Class named CTest)
> *************** ****
> Type VBStruct
> d As Date
> e As Integer
> o As Double
> h As Double
> l As Double
> c As Double
> v As Long
> oi As Long
> End Type
>
> Public Sub TestCall(ByRef data() As VBStruct)
> MsgBox "FillArrayStruc t_Double : INSIDE AX CALL" // L4
> End Sub
>
>
> *************** *******
> C# Test Application : (AX_DLL is the namespace viewed from c#)
> *************** *******
> AX_DLL.CTest MyTest; // Active X DLL
> AX_DLL.VBStruct[] array_struct = null;
> MyTest = new AX_DLL.CTest();
> startTime = DateTime.Now.Ti cks;
> MessageBox.Show ("before alloc...");
> array_struct = new AX_DLL.VBStruct[3000000]; // L1
> MessageBox.Show ("before ax call"); // L2
> AX_DLL.TestCall (ref array_struct_do uble); // L3
> MessageBox.Show ("after ax call"); // L5
>
>
>
>
> With this code, 'L1' is immediate to execute,
> but, it takes quite some long time to go from
> L2->L3->L4, and same long time to go through
> L4->L5.
>
> If you replace L1 with
> array_struct = new AX_DLL.VBStruct[10]; // L1
> everything gets very fast, no wait between calls...
>
> The only cause of the slowness is passing a big array as a parameter.
>
> Do you have an idea ?
>
> Regarding the thread issue, if I put all the C# code above inside a
> background STA Thread, the main UI stills blocks approximatively at the
> same lines...
>
>
> Regards,
> Cybertof.
>[/color]

Eek!!, an array of 3000000 structs (UDT in VB), I thought you were talking
about doubles. Not suprisingly it takes some time to call a method what did
you expect?

Your array takes 3M * 48 bytes ~140MB managed memory + the same amount
because it must be marshaled to unmanaged memory. That means ~300MB of
Memory taken by this single array.
If you don't have that amount free RAM - and I guess THAT'S YOUR PROBLEM,
the system will start trashing, and the time to marshal the call can tens of
seconds maybe minutes. Even if you have that amount of memory free, it will
take several seconds maybe ten to marshal.
I'm not clear why you need to pass such amount of data between managed and
unmanaged world, but this is not the best solution anyway.

Willy.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

In article <u7OvoF3SFHA.16 0@TK2MSFTNGP10. phx.gbl>,
willy.denoyette @telenet.be says...[color=blue]
>
>Eek!!, an array of 3000000 structs (UDT in VB), I thought you were >>[/color]
talking[color=blue]
>about doubles. Not suprisingly it takes some time to call a method what
>did
>you expect?[/color]
[color=blue]
>Your array takes 3M * 48 bytes ~140MB managed memory + the same amount
>because it must be marshaled to unmanaged memory. That means ~300MB of
>Memory taken by this single array.
>If you don't have that amount free RAM - and I guess THAT'S YOUR >[/color]
PROBLEM,[color=blue]
>the system will start trashing, and the time to marshal the call can >[/color]
tens of[color=blue]
>seconds maybe minutes. Even if you have that amount of memory free, it
>will
>take several seconds maybe ten to marshal.
>I'm not clear why you need to pass such amount of data between managed
>and
>unmanaged world, but this is not the best solution anyway.
>
>Willy.[/color]


Willy,

Thanks for your answer.

3000000 was for exagerating the test, because I have also noticed some
slowness in smaller arrays.
Ok for the speed needed, but why does it block the main UI Thread even
when the c# is in a backgroud STA thread ?

The idea of the background thread is not to slow the UI, even with a
long task duration (like this one).

In this case, the code is launched from the main UI Thread :

Thread m_WorkerThread;
m_WorkerThread = new Thread(new ThreadStart(MyT hreadProcess.Te stMe));
m_WorkerThread. IsBackground = true;
m_WorkerThread. Name = "ThreadNorm al";
m_WorkerThread. ApartmentState = System.Threadin g.ApartmentStat e.STA;
m_WorkerThread. Priority = System.Threadin g.ThreadPriorit y.Normal;
m_WorkerThread. Start();

(MyThreadProces s is an instance of a class making the call in my
previous code, through the TestMe method)

If I put a lower priority, it does not change, from time to time, the
main UI Thread still blocks...


Christophe.

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cda98 b05008867798969 7@news.wanadoo. fr...[color=blue]
> In article <u7OvoF3SFHA.16 0@TK2MSFTNGP10. phx.gbl>,
> willy.denoyette @telenet.be says...[color=green]
>>
>>Eek!!, an array of 3000000 structs (UDT in VB), I thought you were >>[/color]
> talking[color=green]
>>about doubles. Not suprisingly it takes some time to call a method what
>>did
>>you expect?[/color]
>[color=green]
>>Your array takes 3M * 48 bytes ~140MB managed memory + the same amount
>>because it must be marshaled to unmanaged memory. That means ~300MB of
>>Memory taken by this single array.
>>If you don't have that amount free RAM - and I guess THAT'S YOUR >[/color]
> PROBLEM,[color=green]
>>the system will start trashing, and the time to marshal the call can >[/color]
> tens of[color=green]
>>seconds maybe minutes. Even if you have that amount of memory free, it
>>will
>>take several seconds maybe ten to marshal.
>>I'm not clear why you need to pass such amount of data between managed
>>and
>>unmanaged world, but this is not the best solution anyway.
>>
>>Willy.[/color]
>
>
> Willy,
>
> Thanks for your answer.
>
> 3000000 was for exagerating the test, because I have also noticed some
> slowness in smaller arrays.
> Ok for the speed needed, but why does it block the main UI Thread even
> when the c# is in a backgroud STA thread ?
>
> The idea of the background thread is not to slow the UI, even with a
> long task duration (like this one).
>
> In this case, the code is launched from the main UI Thread :
>
> Thread m_WorkerThread;
> m_WorkerThread = new Thread(new ThreadStart(MyT hreadProcess.Te stMe));
> m_WorkerThread. IsBackground = true;
> m_WorkerThread. Name = "ThreadNorm al";
> m_WorkerThread. ApartmentState = System.Threadin g.ApartmentStat e.STA;
> m_WorkerThread. Priority = System.Threadin g.ThreadPriorit y.Normal;
> m_WorkerThread. Start();
>
> (MyThreadProces s is an instance of a class making the call in my
> previous code, through the TestMe method)
>
> If I put a lower priority, it does not change, from time to time, the
> main UI Thread still blocks...
>
>
> Christophe.
>[/color]

Again, I guess your COM object runs on the UI thread. Changing the priority
makes no sense, the CLR doesn't care about it when marshaling between
threads.
Beware if you create the instance of the COM object in MyThreadProcess
constructor, you are effectively creating an instance on the UI thread.
Please post your thread procedure or better the MyThreadProcess , the part
that creates the thread doesn't tell where you create an instance of the COM
object.
Also needed are some figures like your OS and memory size, framework
version...

Willy.