← Back to team overview

opencog-dev team mailing list archive

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