Setting up a Garbage Collection Thread

Colin Angus Mackay -- colin.angus.mackay@dial.pipex.com
Wednesday, December 11, 1996

Environment: VC++ 4.1, Win 95, Win NT 3.51, Win NT 4.0

Hi,

I was wondering if anyone could help.

I have an application, but in certain instances the return to user time
after some functions is too long (especially if large lists of objects
are to be deleted in the process) . One idea I was thinking on cutting
down on this would be to set up a garbage collection thread and then in
some classes' destructors send the pointers to objects created on the
heap to the Garbage collector for processing after making sure that all
references to that object have also be terminated.

My theory is that as the Garbage Collection is being done on a separate
thread the return to user time will be faster when a large number of
objects are being deleted, especially on classes with large CList, CMap
or CArray objects on board.

My questions are:

*	Is this wise?

*	Is this possible? (passing pointers between threads, etc.)

*	Any help on starting out on this venture? as I have never used threads
before.

Any help is very much appreciated,
Thanks,

Colin Angus Mackay.

---

Roma -- roma@neonet.lv
Sunday, December 15, 1996

Colin Angus Mackay wrote:
> 
> Environment: VC++ 4.1, Win 95, Win NT 3.51, Win NT 4.0
> 
> Hi,
> 
> I was wondering if anyone could help.
> ...One idea I was thinking on cutting
> down on this would be to set up a garbage collection thread and then in
> some classes' destructors send the pointers to objects created on the
> heap to the Garbage collector for processing after making sure that all
> references to that object have also be terminated.
> 
> My theory is that as the Garbage Collection is being done on a separate
> thread the return to user time will be faster when a large number of
> objects are being deleted, especially on classes with large CList, CMap
> or CArray objects on board.
  You can also use OnIdle to delete this garbage - just like the MFC's
temporary pointers are deleted.
  Another possible solution is to use HeapAlloc()/HeapDestroy() pair.
This techique is described in Jeffrey Richter's 'Advanced Windows',
Chapter 8, p. 272.
The main idea is that you are allocating ALL objects (which you  gonna
store in your CLsit's, CArray's, etc.) in one big piece of memory, which
can be destroyed at once - without going through all objects and calling
delete for each.
Richter shows the usage Heap, but it can be a GlobalAlloc'ed memory, or
just big 'new char[MAX_POSSIBLE_SIZE]' as well....
 
> 
> My questions are:
> *       Is this wise?
	Well, probably yes. This really should make return to user time faster.
	Also you will study multythreading - not a bad thing by itself.

> *       Is this possible? (passing pointers between threads, etc.)
> *       Any help on starting out on this venture? as I have never used threads
> before.
	Yes, it's possible to path pointers between threads.
	All threads of the process are running in the single adress space
that's 
	why you can access global variables from any thread in the process. 
	There is a problem though - all threads are working simultaneously
	even if you have single-processor computer. This means that one thread 
	can try to read global variable, while the second thread is writing to
this
	variable at the same time. You have to implement synchronization with 
	semaphores, etc...
	All this is discussed i the Richter's book.

	Check this in MFC documentation:
        C++ books
	   MFC 4.0
	      Programming w/ MFC: Encyclopedia
		Multythreading
	
	This explains in details how to use all this stuff in MFC...

> Any help is very much appreciated,
> Thanks,
> 
> Colin Angus Mackay.
Hope this will helps
And sorry for my English.

-Roma Guralnik

---

| Вернуться в корень Архива |