The code for this is obsolete and has been removed. It never worked right.
Warning: This page describes a concept that might be better understood as an "OpenCog Control Panel". It talks about "agents", but that seems off the mark. That is, we want to provide users with some way of starting and stopping various different subsystems, possibly on a distributed network of machines. We want to be able to easily find and load the correct dataset or datasets (the "memories" and "knowledge" of the system), to checkpoint the system, in case it crashes, and to save partial or final results. We want to manage the configuration of the system. We want to allow the user to make sure that the appropriate systems are not starved for CPU time, and to monitor overall system performance. Finally, large parts of this need to be automated and automatable, so that the attention allocation subsystem can control overall resource scheduling. In the long run, this is what an Agent needs to be: a schedulable processing resource.
A MindAgent is a software module that performs computations. MindAgents can be thought of as processes or threads; in most cases, they should be implemented as threads. The parallelizing OpenCog page explains some current ideas for creating and working with agents.
Warning: The description below describes semi-obsolete code that never worked correctly. It is a kind-of wish-list for how it might be nice to have things work. The reality is that using threads is much easier than trying to implement cooperative multi-threading, as described below. Perhaps it is a bad idea to try to re-invent operating system kernel concepts in user-space, which is what "Agents" seems to be trying to do. OpenCog is already complex; we don't need to make it into an operating system, too. At least, not yet.
The current MindAgent code in the CogServer combines four distinct functions:
- The ability to load the code for a MindAgent as a dynamically loadable module (shared library, DSO, DLL). This allows new MindAgents to be inserted into an already-running CogServer.
- The ability to start and stop MindAgents. The CogServer command-line interface allows agents to be manually stopped and started.
- An extremely simple, minimal scheduler, for allowing multiple MindAgents safely access code that is not thread-safe. Most MindAgents should use threads to perform their work; however, some parts of OpenCog are not currently thread-safe; code that touches these parts must use the scheduler.
- The MindAgent provides a mechanism for declaring which Atoms are important to the agent. This mechanism interacts with the AttentionAllocation subsystem for guiding inference. XXX This mechanism is currently undocumented and needs documenting! XXX
There is a very simple scheduler implemented in the CogServer code base. It is there for only one reason: to allow different MindAgents to access those parts of the OpenCog subsystem that are not yet thread-safe.
At this time, Atoms, TruthValues, AttentionValues and the AtomSpace are all thread-safe. The TimeServer, SpaceServer, LearningServer, OAC and PAI are probably not thread-safe. Thus, you only need to use scheduling MindAgents for accessing embodiment code; otherwise, please create a thread in which to do processing.
Please note that the MindAgent dispatcher code is extremely simple, and is guaranteed to suffer from various textbook ills, such as deadlocks, priority inversion, stalls. Its not pre-emptive, its not fair, its just a simple loop. Thus, MindAgents should be kept very simple, should run only for very small intervals of time, and should avoid anything that would cause them to sleep or block. If any agent blocks, they all block. No agent can run until the current agent has finished running. This is why threads are encouraged: the 'run' method should be trivial.
Since the scheduler only runs in one thread on one core, it is fundamentally unable to make use of modern multi-core CPU's. The correct long term solution is to make all public API's in the OpenCog codebase thread-safe.
Examples of Mind Agents are:
- ForgettingAgent - Removes Atoms from the AtomSpace with an LTI below a certain threshold (which are therefore deemed to no longer be needed / relevant), so memory space is freed for the storage of new information
- ImportanceUpdatingAgent - Updates the STI and / or LTI of Atoms in the Atomspace based on their changing relevance / usefulness over time.