Agent Input-Ouput System (AIOS)

The Agent Input-Output System (AIOS) is the interface and abstraction layer between agents programmed in AgentJS and the agent processing platform (JAM). Furthermore, it provides an interface between host applications and JAM.

figaios

Interface between agents and JAM and between JAM and a host application: Agent Input-Output System (AIOS)

Agent Scheduling and Check-pointing

JS has a strictly single-threaded execution model with one main thread, and even by using asynchronous callbacks, these callbacks are executed only if the main thread (or loop) terminates. This is the second hard limitation for the execution of multiple agent processes within one JS JAM platform. Agents processes are scheduled on activity level, and a non-terminating agent process activity would block the entire platform. Current JS execution platform including VMs in WEB browser programs provide no reliable watchdog mechanism to handle non-terminating JS functions or loops. Though some browsers can detect time outs, they are only capable to terminate the entire JS program. To ensure the execution stability of the JAM and the JAM scheduler, and to enable time-slicing, check-pointing must be injected in the agent code prior to execution. This step is performed in the code parsing phase by injecting a call to a checkpoint function CP() at the beginning of a body of each function contained in the agent code, and by injecting the CP call in loop conditional expressions. Though this code injection can reduce the execution performance of the agent code significantly, it is necessary until JS platforms are capable of fine-grained check-pointing and thread scheduling with time slicing. On code-to-text transformation (e.g., prior to a migration request), all CP calls are removed.

AIOS provides a main scheduling loop. This loop iterates over all logical nodes of the logical world, and executes one activity of all ready agent processes sequentially. If an activity execution reaches the hard time-slice limit, a SCHEDULE exception is raised, which can be handled by an optional agent exception handler (but without extending the time-slice). This agent exception handling has only an informational purpose for the agent, but offers the agent to modify its behaviour. All consumed activity and transition execution times are accumulated, and if the agent process reaches a soft run-time limit, an EOL exception is raised. This can be handled by an optional agent exception handler, which can try to negotiate a higher CPU limit based on privilege level and available capabilities (only level-2 agents). Any ready scheduling block of an agent and signal handlers are scheduled before activity execution.

After an activity was executed, the next activity is computed by calling the transition function in the transition section.

In contrast to the AAPL model that supports multiple blocking statements (e.g., IO/tuple-space access) inside activities, JS is not capable of handling any kind of process blocking (there is no process and blocking concept). For this reason, scheduling blocks can be used in AgentJS activity functions handled by the AIOS scheduler. Blocking AgentJS functions returning a value use common callback functions to handle function results, e.g., inp(pat,function(tup){..}).

A scheduling block consists of an array of functions (micro activities), i.e., B(block) = B([function(){..}, function(){..},...])., executed one-by-one by the AIOS scheduler. Each function may contain a blocking statement at the end of the body. The this object inside each function references always the agent object. To simplify iteration, there is a scheduling loop constructor L(init, cond, next, block, finalize) and an object iterator constructor I(obj, next, block, finalize), used, e.g., for array iteration. Agent execution is encapsulated in a process container handled by the AIOS. An agent process container can be blocked waiting for an internal system-related IO event or suspended waiting for an agent-related AIOS event (caused by the agent, e.g., the availability of a tuple). Both cases stops the agent process execution until an event occurred.

The basic agent scheduling algorithm is shown in the following algorithm and consists of an ordered scheduling processing type selection, i.e., partitioning agent processing in agent activities, transitions, signals, and scheduling blocks. In one scheduler pass, only one kind of processing is selected to guarantee scheduling fairness between different agents. There is only one scheduler used for all virtual (logical) nodes of a world (a JAM instance). A process priority is used to alternate activity and signal handling of one agent, preventing long activity and transition processing delays due to chained signal processing if there are a large number of signals pending.

∀ node ∈ world.nodes do
 ∀ process ∈ node.processes do
  Determine what to do with prioritized conditions:
    Order of operation selection:
    0. Process (internal) block scheduling [block]
    1. Resource exception handling
    2. Signal handling [signals]
       - Signals only handled if process priority < HIGH 
       - Signal handling increase process priority temporarily to 
         allow low-latency act/trans scheduling!
    3. Transition execution
    4. Agent schedule block execution [schedule]
    5. Next activity execution
       - Lowers process priority
  if process.blocked or process.dead or 
   process.suspended and process.block=[] and process.signals=[] or
   process.agent.next=none and process.signals=[] and
   process.schedule=[]
    then do nothing
  elseif not process.blocked and process.block≠[]
    then execute next block function 
  elseif agent resources check failed 
    then raise EOL exception
  elseif process.priority < HIGH and process.signals≠[]
    then handle next signal, increase process.priority
  elseif not process.suspended and process.transition
    then get next transition 
    or execute next transition handler function
  elseif not process.suspended and process.schedule≠[]
    then execute next agent schedule block function
  elseif not process.suspended
    then execute next agent activity and compute next transition, 
      decrease process.priority

Algorithm: JAM Agent Scheduler