Agent (Obsolete)
An OpenCog Agent was meant to be a schedulable process or thread that performed some sort of computation on data residing within the AtomSpace. The Agent subsystem is one of the OpenCog Fossils.
The idea of having some sort of agent subsystem that is able to manage, schedule, control and coordinate agents remains a valid and useful idea for AGI. However, the actual implementation suffered from multiple deep and fundamental problems:
- It attempted to reinvent basic operating system concepts, in a naive and unprincipled way. It provided a single-threaded cooperative multi-tasking scheduler. Cooperative multi-tasking was a OS design principle that was implemented in the ancient (original) Apple Macintosh and Microsoft Windows 3.1 systems; it was discarded as a valid concept by the 1990's. It has no place in a modern system.
- No multi-threading support. No ability to schedule jobs across multiple servers, or across a compute cluster. A modern implementation of Agents would need to be able to schedule on top of cloud platforms.
- No well-defined agent-management system, other than ECAN. For example, the MOSES system maintains a collection of trees, each resembling a decision tree. The system resembles a "decision forest", and, as such, is a viable model for scalable machine learning. Each tree can "cast a vote" and thus help determine a decision problem. Each tree can be thought of as an "agent". Such trees are much, much too small to be scheduled individually; however, the idea of giving agents a "vote" or using a pool of agents to solve a problem remains valid. But the practical details for doing this remain unexplored, undetermined.
Obsolete
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
The Scheduler
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
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.
Using
A list of currently installed agents can be gotten from the CogServer shell; these can also be individually started and stopped.
