Re: Fast allocation vs lightweight collection

On 08/25/03 David Jeske wrote:
> > Reference counting, for instance, needs some form of locking when
> > updating the reference counts, unless you rely on the application to
> > do its own locking and not modify a pointer from two threads.
> 
> Because objects are never moved, the only "unsafe" thing to do is
> prematurely deallocate an object. This means that locking is only
> required only if many mutators are doing the deallocation and
> finalization.

You need locks to increment/decrement the reference count:

count = 1

thread1 		thread2 	count
reg = count 		reg = count 	1
reg = reg+1 		reg = reg+1 	1
count = reg 		...		2
...			count = reg 	2

at this point count is 2, instead of 3.
Doing the increment/decrement atomically is very expensive: I don't
think refcounting is suitable as the GC mechanism in multithreaded 
programs (unless you want to pay a big performance cost).

lupus

-- 
-----------------------------------------------------------------
[email protected]                                     debian/rules
[email protected]                             Monkeys do it better
_______________________________________________
Mono-gc-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-gc-list