MultiThreading an ActiveX DLL call...

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

In article <ejFnSz9SFHA.39 80@TK2MSFTNGP12 .phx.gbl>,
willy.denoyette @telenet.be says...
[color=blue]
>Beware if you create the instance of the COM object in MyThreadProcess
>constructor, you are effectively creating an instance on the UI thread.
>Willy,[/color]




You were right....the instanciation of the ActiveX was done in the
constructor, so in the main UI !
I have moved the instanciation to the method, and now it's better.

Last question :
How do you release memory allocated like this :
array_struct = new AX_DLL.VBStruct[3000000];

Is
array_stuct = null;
enough with the marshalling ?

I have tried to call a GC.Collet() inside the thread before it
terminates, but GC.Collet() does not seem to run into the background
thread, does it ?


Regards,
Cybertof.

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cdb0d fd486413d989698 @news.wanadoo.f r...[color=blue]
> In article <ejFnSz9SFHA.39 80@TK2MSFTNGP12 .phx.gbl>,
> willy.denoyette @telenet.be says...
>[color=green]
>>Beware if you create the instance of the COM object in MyThreadProcess
>>constructor , you are effectively creating an instance on the UI thread.
>>Willy,[/color]
>
>
>
>
> You were right....the instanciation of the ActiveX was done in the
> constructor, so in the main UI !
> I have moved the instanciation to the method, and now it's better.
>
> Last question :
> How do you release memory allocated like this :
> array_struct = new AX_DLL.VBStruct[3000000];
>
> Is
> array_stuct = null;
> enough with the marshalling ?
>
> I have tried to call a GC.Collet() inside the thread before it
> terminates, but GC.Collet() does not seem to run into the background
> thread, does it ?
>
>
> Regards,
> Cybertof.[/color]

Yes,
array_stuct = null;
GC.Collect();
forces a GC run and frees the memory taken by the array_stuct, with such
large structs one of the legitime uses of GC.Collect(). What makes you think
it doesn't run on the background thread?
When done with the COM object your should call Marshal.Release ComObject(...)



Willy.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

In article <eN4o9dATFHA.25 56@TK2MSFTNGP12 .phx.gbl>,
willy.denoyette @telenet.be says...[color=blue]
> Yes, array_stuct = null;
> GC.Collect();
> forces a GC run and frees the memory taken by the array_stuct, with such
> large structs one of the legitime uses of GC.Collect(). What makes you think
> it doesn't run on the background thread?
> When done with the COM object your should call Marshal.Release ComObject(...)
> Willy.[/color]


Thanks for the hint about the Marshal.Release ComObject(...).

What made me think it does not run on the background thread is :
If I put the GC.Collect() on the big array, it slows down the main UI.
If I remove the GC.Collect(), the main UI is not affected.

Does it sound correct to you ?

GC.Collect() is a static method, not instancied within a thread, so
where does it execute ? It 'touches' all orphelin memory parts, from all
threads within the main process ?


Cybertof.

[Cybertof]

Re: MultiThreading an ActiveX DLL call...

Willy ? are you here ?

[VC# Jones]

Re: MultiThreading an ActiveX DLL call...

If you open up mscorlib.dll with ILDASM and look at GC.Collect() you will see
it eventually gets to the private method GC.nativeCollec tGeneration(). You
will see that this is marked with the pseudoattibute "internalca ll" and that
the actual code of it is blank. This is because the Collection occures within
the .NET Runtime itself and not anywhere in your code.

However, it still poses a bigger threat. Since GC works with "generation s",
whenever Garbage Collection occures, the entire Runtime for that application
will pause during collection, reguardless of threads. I would recommend
setting what you don't need as null, but don't call collection. When GC does
happen on it's own and it sees that it is null, it won't hesitate to collect
it.

Another factor about collection is resurrection. Resurrection is exactly as
it sounds. When an application is no longer accessing a live object, the
garbage collector considers the object to be dead. However, if the object
requires finalization, the object is considered live again until it is
actually finalized, and then it is permanently dead. In other words, an
object requiring finalization dies, lives, and then dies again. When the
object is going to be finalized, avoid multiple resurections, or worse, a
loop where the object is called for finalization, resurrected, and then set
for finalization again, then finalized, so it get's stuck.

Be careful when working with static or global objects as well. Something
like this would hurt:

public class BaseObj {

~BaseObj() {
Application.Obj Holder = this;
}
}

class Application {
public static Object ObjHolder; // Defaults to null
....
}

Note about how GC works in the Framework, objects that are 20,000 bytes or
larger are placed on a special heap. This is transparent so the developer nor
the actual code itself will know it. As far as it is concerned, it is one
heap. The reason for this is the special heap is never compacted. Shifting
20,000 bytes or more down the heap will require too much CPU time.

Generally I would recommend not calling collection on your own unless you
have very good reasons.

"Cybertof" wrote:
[color=blue]
> In article <eN4o9dATFHA.25 56@TK2MSFTNGP12 .phx.gbl>,
> willy.denoyette @telenet.be says...[color=green]
> > Yes, array_stuct = null;
> > GC.Collect();
> > forces a GC run and frees the memory taken by the array_stuct, with such
> > large structs one of the legitime uses of GC.Collect(). What makes you think
> > it doesn't run on the background thread?
> > When done with the COM object your should call Marshal.Release ComObject(...)
> > Willy.[/color]
>
>
> Thanks for the hint about the Marshal.Release ComObject(...).
>
> What made me think it does not run on the background thread is :
> If I put the GC.Collect() on the big array, it slows down the main UI.
> If I remove the GC.Collect(), the main UI is not affected.
>
> Does it sound correct to you ?
>
> GC.Collect() is a static method, not instancied within a thread, so
> where does it execute ? It 'touches' all orphelin memory parts, from all
> threads within the main process ?
>
>
> Cybertof.
>
>
>[/color]

[Willy Denoyette [MVP]]

Re: MultiThreading an ActiveX DLL call...


"Cybertof" <cybertofNOSPAM @ifrance.com> wrote in message
news:MPG.1cdb60 d0b0a082cc98969 9@news.wanadoo. fr...[color=blue]
> In article <eN4o9dATFHA.25 56@TK2MSFTNGP12 .phx.gbl>,
> willy.denoyette @telenet.be says...[color=green]
>> Yes, array_stuct = null;
>> GC.Collect();
>> forces a GC run and frees the memory taken by the array_stuct, with such
>> large structs one of the legitime uses of GC.Collect(). What makes you
>> think
>> it doesn't run on the background thread?
>> When done with the COM object your should call
>> Marshal.Release ComObject(...)
>> Willy.[/color]
>
>
> Thanks for the hint about the Marshal.Release ComObject(...).
>
> What made me think it does not run on the background thread is :
> If I put the GC.Collect() on the big array, it slows down the main UI.
> If I remove the GC.Collect(), the main UI is not affected.
>
> Does it sound correct to you ?
>
> GC.Collect() is a static method, not instancied within a thread, so
> where does it execute ? It 'touches' all orphelin memory parts, from all
> threads within the main process ?
>
>
> Cybertof.
>
>[/color]

GC.Collect() forces a full collect, that is all generations are scanned for
non rooted objects during a sweep.
The GC.Collect() obviously runs on the thread that initiated the call (it
calls into the CLR), once started the CLR suspends all managed threads and
prevent all unmanaged threads to return or call into managed code.
Now in your particular case, it might take some time to collect and as such
it might have a visible impact on the UI. Simply put the data you are
handling is too large.


Willy.