Re: Fast allocation vs lightweight collection

On Mon, Aug 25, 2003 at 07:12:27PM +0200, Paolo Molaro wrote:
> > 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:

It's pretty easy to avoid locking using the atomic test/set/exchange
operations of modern processors.

For example, x86 has "cmpxchg", the psudocode of this operation is:

  [ http://www.geocities.com/bkartheek/files/chap6.htm ]

        cmpxchg         operand1, operand2  [ ax/al/eax = compare_to ]

        if ({al/ax/eax} = operand1) then

                zero := 1               ;Set the zero flag
                operand1 := operand2

        else

                zero := 0               ;Clear the zero flag
                {al/ax/eax} := operand1

        endif

Using this, you can do:

try_again:
  reg = mem(count)
  compare_to = reg
  reg = reg + 1      // or reg = reg -1
  if (! cmpxchg mem(count),reg [ compare_to ] ) {
    yeild(); // optional
    goto try_again;  
  } 

When two threads collide, this looks like:
  
thread1 		thread2 		mem(count)
reg = mem(count)	reg = mem(count) 	1
reg = reg+1 		reg = reg+1 		1
cmpxchg suceeds 	cmpxchg fails		2
...			reg = mem(count)	2
			reg = reg+1		2
			cmpxchg suceeds		3
			...

No locking required.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [email protected]

_______________________________________________
Mono-gc-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-gc-list