Re: Weak pointers

Kohler Markus (kohlerm@betze.bbn.hp.com)
Tue, 18 Mar 1997 16:37:42 +0000

Message-Id: <199703181637.RAA27735@betze.bbn.hp.com>
To: Wolfgang Lux <lux@heidelbg.ibm.com>
Subject: Re: Weak pointers
In-Reply-To: lux's message of Tue, 18 Mar 1997 16:54:19 +0100.
<9703181554.AA46238@idse.heidelbg.ibm.com>
Date: Tue, 18 Mar 1997 16:37:42 +0000
From: Kohler Markus <kohlerm@betze.bbn.hp.com>

> > [...]
> > > You can use them to implement hash-consing. Assume you have some t=
ree
> > > data structure. If you want to share the nodes wherever possible, =
you
> > > can put every created node into a hash table. Then when you are ab=
out
> > > to create a new node, you first look in the hash table to see if th=
e
> > > same node has already been created. If this is the case, you retur=
n
> > > the old one from the hash table instead of creating a new one.
> > > =

> > > But the above prevents the GC from collecting the nodes when they
> > > become unused, because they will always be reachable from the hash
> > > table. If you use weak pointers in your hash table, the GC will be=

> > > able to deallocate the dead nodes, but you still can have access to=

> > > the live ones through the weak pointers.
> > > =

> > =

> > I'm not sure if it makes sense to implement such a tree with weak poi=
nters. =

> > To be honest, I think it's not a good idea to do so. =

> > =

> > The problem is that if you delete an element in the tree it may be th=
at the =

> > hash table still points to the node, because there was no garbage col=
lection =

> > yet. It could be possible that you would still find the entry trough =
the hash =

> > table.
> =

> Surely this is possible, but I do not see why this should be a problem.=
=

> It will just prevent you from creating an identical copy of an element =

> which had been present in the hash table.
> =

Ok, in this case it's no problem.

> > =

> > IMHO the real solution is to implement a delete method for the tree w=
hcih =

> > takes care of all that internal pointers. =

> > =

> =

> No. The delete method for the tree is the wrong place. You would link =

> your tree implementation hardly with the use of the hash table and =

> disallow the use of the data structure without a hash table or with =

> another hash table implementation. This does not seem good software =

> engineering practice to me.
>

That's no problem. In some sense this Tree is not a Tree but some kind of=
=

directed graph. This graph datastructure could use a hash table and a tre=
e by =

aggregation for example.

There's n reason why this datastructures has to use a specific hash table=
=2E =

If one deletes a node in graph this means that ALL references to the node=
hav =

to be deleted. =

=

> BTW, in implementing such a method you would have to implement some =

> kind of weak pointer yourself. =

If I would like to implement reuse of already deleted objects, perhaps =

something similiar would be necessary. =

> A data structure might be an element in =

> more than one tree so would have to keep reference counts as well to be=
=

> sure that you can remove a data structure from the hash table.

Same argument as above, combining several trees probably means creating a=
new =

datastructure, which should use appropriate delete methods. =

This also has to do with the finalization mechanism. If a finalize method=
is =

called when the object is destroyed, the object could tell all it's depen=
ds " =

"hey I'm going to be deleted". This is not directly related to weak poi=
nters.

> =

> I would admit that weak pointers are some dirty kind of feature in the =

> language and I'm not quite happy that they. It is very easy to write =

> programs in the presence of weak pointers, whose outcome is completly =

> random. But in some cases like the one of Damien's example it may be =

> the least dirty one.
> =

> > By the way, I know what I'm speaking about because we have here an ap=
plication =

> > using the same idea to implement some kind of cache. I does not work =
properly =

> > because nobody knows at which point of time the garbage collector thr=
ows way =

> > the objects. =

> =

> Sure. But this only demonstrates the fact, that you have to use weak po=
inter with care. If you work with objects where a data structure which is=
recreated differs from a data structure that is refetched from the cache=
, weak pointers are really not applicable. (And maintaining cache consist=
ency is not trival at all in this case!)

I agree with that point. =

Markus =

-- =

+------------------------------------------------------------------------=
----+
| Markus Kohler Hewlett-Packard GmbH =
|
| Software Engineer Network & System Management Divi=
sion| =

| IT/E Success Team =
|
+------------------------------------------------------------------------=
----+