← Back to team overview

opencog-dev team mailing list archive

Re: Locking atoms

 

I believe other mindagent scheduling constraints exist, like mutual
exclusivity and sequence dependence.

Could the cogserver impose its scheduling constraints on mindagent processes
via multiple mechanisms, like simple process control (spawning, stop, start,
wait, etc.), message passing (cooperative interrupt with libevent or similar
would be required for non-concurrent-safe or non-stoppable mindagents), etc?

-dave

On Wed, Jul 2, 2008 at 2:25 PM, Joel Pitt <joel.pitt@xxxxxxxxx> wrote:

> Hi Gama,
>
> I going through the threading code, and read about users of the
> Atom::getNeighbours method having to lock atoms manually.
>
> I was wondering how I'd go about this, since I use the function
> relatively frequently and want to be prepared for when you merge the
> threading code.
>
> The AtomSpace and AtomTable test examples seem to lock the entire
> table. Do I need to do the same thing while processing the
> neighbouring atoms, or is there a finer level of locking available
> somehow?
>
> Also, thinking about your idea of having mind agents as separate
> threads with scheduling handled by the OS. I like the idea... are you
> planning to have the server control the scheduling at all though?
> Certain mind agents should only run so often, whereas others will use
> as much CPU as they can their hands on! I guess this would be handled
> by appropriately placed sleep calls though.
>
> Thanks!
>
> J
>
> _______________________________________________
> Mailing list: https://launchpad.net/~opencog-dev<https://launchpad.net/%7Eopencog-dev>
> Post to     : opencog-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~opencog-dev<https://launchpad.net/%7Eopencog-dev>
> More help   : https://help.launchpad.net/ListHelp
>

References