opencog-dev team mailing list archive

["Linas Vepstas" <linasvepstas@xxxxxxxxx>]

Work on threading in opencog is on-hold because it seems
like a difficult problem. However, I was reading something recently,
which makes me think that perhaps a change of mindset could
convert this difficult problem into an "easy" one, by changing certain
core assumptions.

I was reading about Clojure
http://wiki.jvmlangsummit.com/pdf/27_Hickey_clojure.pdf

which is a LISP implementation on top of the JVM. One of the things
that Hickey talks about is multi-threading, and how "easy" it is, because
of a core design assumption he made: expressions would be immutable.

This rang a bell: the hypergraphs in opencog are currently "immutable",
in the sense that, once I create something like

   SomeLink
      SomeAtom "asdf"
      OtherAtom "pqrs"

I can not change the string values "asf" or "pqrs", I cannot add more
atoms to the link, I cannot remove the existing  atoms from the link,
I cannot delete these atoms from the link, unless I also delete the link
first. So at least one key concept from clojure already exists in
opencog: immutablity.

The key element that seems to be missing from opencog is
garbage collection.  That is, although the incoming set for
"SomeAtom" will reveal that "SomeLink" is pointing at it, we
don't know who is pointing at SomeLink. Thus, there is no safe
way of deleting "SomeLink" if there is more than one "MindAgent"
(forget threads -- even when single threaded, if one MindAgent
is holding a pointer to SomeLink, its unsafe to delete it).

If garbage collection was added, I think the multi-threading issues
just might go away (I haven't pondered deeply on this, though).

I'm also thinking that adding something conservative, like the
Boehm garbage collector, might be pretty easy, almost trivially
so, as it might not require any big tear-up of the code ... or even
a small tear-up.  The only interesting pieces would be to integrate
it properly with the ForgettingAgent, and &etc. -- and I guess with
the TLB and handles, since these act as pseudo-pointers.

Anyone care to ponder this in greater detail?

--linas