[Gc] gcc_support.c & WeakPointers

Boehm, Hans hans_boehm@hp.com
Thu, 6 Nov 2003 14:22:31 -0800


GC_call_with_alloc_lock() is technically necessary if you have multiple
threads, since otherwise it may be written by the collector as you're reading it,
and pthreads, for example, disallows that.

In fact, if you access the actual pointer as a volatile without locking,
and you are running on reasonably sane hardware which allows atomic
updates of pointers, you are probably fine without that.   (Actually,
since the collector stops threads, you really just need to make sure that
no thread can be interrupted half-way through reading a pointer.)

Of course you also don't need the lock for single-threaded code, though
GC_call_with_alloc_lock basically just adds function call overheads in that
case.

Hans

> -----Original Message-----
> From: gc-admin@napali.hpl.hp.com [mailto:gc-admin@napali.hpl.hp.com]On
> Behalf Of teelf@nymph.kyndig.com
> Sent: Thursday, November 06, 2003 12:13 PM
> To: gc@napali.hpl.hp.com
> Subject: RE: [Gc] gcc_support.c & WeakPointers
> 
> 
> 
> Now I understand why the WeakPointer functions wrap the pointer in a 
> GC_MALLOC_ATOMIC object.  And I should still use the 
> GC_call_with_alloc_lock function to get the pointer value of the 
> WeakPointer?
> 
> I just tried a version of the WeakPointers with the code for 
> Descriptors 
> removed.  It seems to be working.  Since I don't any any 
> finalizers, this 
> should be ok? 
> 
> Thanks a lot for the help.
> 
> - Lee Faris
> 
> On Thu, 6 Nov 2003, Boehm, Hans wrote:
> 
> > You should almost certainly not be using gcc_support.c.  I 
> just removed it
> > from the distribution to avoid further confusion.  It was 
> there to support
> > an gcc extension which was never fully released.  I 
> included it for a while
> > in the hope that someone might resurrect it or be able to 
> recycle pieces of it,
> > and then forgot about it.
> > 
> > I haven't looked at the weak pointer class in gcc_support.c 
> recently.
> > You may be able to resurrect it.  If so, it might make 
> sense to extract it
> > and put it back in the distribution.  If you need simple 
> weak pointers,
> > and don't depend on the precise interaction with finalizers,
> > GC_general_register_disappearing_link together with a 
> pointer that's either
> > disguised (HIDE_POINTER or in preferably a GC_MALLOC_ATOMIC 
> object) allows
> > you to do that fairly easily.
> > 
> > Hans
> > 
> > > -----Original Message-----
> > > From: gc-admin@napali.hpl.hp.com 
[mailto:gc-admin@napali.hpl.hp.com]On
> > Behalf Of Lee Faris
> > Sent: Thursday, November 06, 2003 1:00 AM
> > To: gc@napali.hpl.hp.com
> > Subject: [Gc] gcc_support.c
> > 
> > 
> > I am not able to use gcc_support.c as I get an undefined reference to
> > __default_new_handler.    I can not find any mention of
> > __default_new_handler anywhere else.  It sounds like 
> > something that would be
> > defined in the stdc++ library (but apparently is not).  Or am 
> > I suppose to
> > set this value to something myself?
> > 
> > I get this error on both gcc 2.96 on linux 2.4.9 and in 
> > VS.net 2003.  Also,
> > in VS.net I get an undefined reference to __new_handler as 
> > well.  And a
> > related question, is gcc_support.c ok to use with visual 
> > studio even though
> > it's called gcc_support.c?  I am assuming so since it implements the
> > weakpointer class.
> > 
> > Thank you for any help with this.
> > 
> > - Lee Faris
> > 
> > 
> > _______________________________________________
> > Gc mailing list
> > Gc@linux.hpl.hp.com
> > http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc
> > 
> _______________________________________________
> Gc mailing list
> Gc@linux.hpl.hp.com
> http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc
> 

_______________________________________________
Gc mailing list
Gc@linux.hpl.hp.com
http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc