caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Wolfgang Lux <lux@heidelbg.ibm.com>
To: Kohler Markus <kohlerm@betze.bbn.hp.com>
Cc: caml-list@pauillac.inria.fr
Subject: Re: Weak pointers
Date: Tue, 18 Mar 97 16:54:19 +0100	[thread overview]
Message-ID: <9703181554.AA46238@idse.heidelbg.ibm.com> (raw)
In-Reply-To: (Your message of Tue, 18 Mar 97 10:09:38 GMT.) <199703181009.LAA23108@betze.bbn.hp.com>

> [...]
> > You can use them to implement hash-consing.  Assume you have some tree
> > 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 about
> > to create a new node, you first look in the hash table to see if the
> > same node has already been created.  If this is the case, you return
> > 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 pointers.
> 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 that the
> hash table still points to the node, because there was no garbage collection
> 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.

>
> IMHO the real solution is to implement a delete method for the tree whcih
> 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.

BTW, in implementing such a method you would have to implement some
kind of weak pointer yourself. 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.

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 application
> 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 throws way
> the objects.

Sure. But this only demonstrates the fact, that you have to use weak
pointer 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 consistency is not trival at all in this case!)

Regards
Wolfgang


----
Wolfgang Lux                     WZH Heidelberg, IBM Germany
Phone: +49-6221-59-4546                Fax: +49-6221-59-3500
Internet: lux@heidelbg.ibm.com          Office: mazvm01(lux)







  reply	other threads:[~1997-03-18 18:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-03-17 19:19 Damien Doligez
1997-03-18 10:09 ` Kohler Markus
1997-03-18 15:54   ` Wolfgang Lux [this message]
1997-03-18 16:37     ` Kohler Markus
1997-03-18 17:32       ` Wolfgang Lux
  -- strict thread matches above, loose matches on Subject: below --
1997-03-30 17:13 Daniel de Rauglaudre
1997-04-01 10:57 ` Pierre Weis
1997-04-01 12:03   ` Daniel de Rauglaudre
1997-03-21 17:26 Damien Doligez
1997-03-20 12:12 Emmanuel Engel
1997-03-20 16:09 ` Kohler Markus
     [not found] <199703181607.RAA13208@tobago.inria.fr>
1997-03-18 17:08 ` Kohler Markus
     [not found] <199703181434.PAA12806@tobago.inria.fr>
1997-03-18 15:51 ` Kohler Markus
1997-03-18  7:43 Kohler Markus
1997-03-11 13:28 Objective Caml 1.04 released Xavier Leroy
1997-03-14  8:40 ` Frank Christoph
1997-03-17  9:13   ` Weak pointers Frank Christoph

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9703181554.AA46238@idse.heidelbg.ibm.com \
    --to=lux@heidelbg.ibm.com \
    --cc=caml-list@pauillac.inria.fr \
    --cc=kohlerm@betze.bbn.hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).