opencog-dev team mailing list archive
-
opencog-dev team
-
Mailing list archive
-
Message #00379
Re: Threading and GC in opencog
Also, of course, the ingoing or outgoing set of an Atom may be changed by a
MindAgent ... why is this not a problem for concurrency?
On Tue, Sep 30, 2008 at 1:51 PM, Linas Vepstas <linasvepstas@xxxxxxxxx>wrote:
> 2008/9/30 Ben Goertzel <ben@xxxxxxxxxxxx>:
> >
> > Linas,
> >
> > But the truth values, attention values, etc. associated with an Atom are
> not
> > immutable ...
> >
> > so for instance, a MindAgent could add a new Version within a
> > CompositeTruthValue
> > object associated with an Atom ...
>
> Hmm. Well, if one thread is looking at a truth value while
> another is setting it, then, in today's system, there would be
> a crash (because the old value is deleted, and
> Atom::getTruthValue() returns a reference).
>
> This could be solved by having AtomTruthValue() return
> a copy, instead of a reference; but then one pays the
> penalty of creating a copy, for each and every access.
> (this is "copy-on-read").
>
> By contrast, in a garbage-collected system, the worst that
> would happen is that someone is looking at an "old, stale"
> truth value; as opposed to crashing. By the principles
> of concurrency, there's "no such thing" as an "old stale
> value" in between synchronization primitives.
>
> --linas
>
--
Ben Goertzel, PhD
CEO, Novamente LLC and Biomind LLC
Director of Research, SIAI
ben@xxxxxxxxxxxx
"Nothing will ever be attempted if all possible objections must be first
overcome " - Dr Samuel Johnson
Follow ups
References