SMAS 2.0b   A Primer

  6. SMAS Internals (Dynamics)

The dynamic corresponds to the functioning of the simulator. During the simulation process agents change state, messages get created and exchanged among the various agents. The simulation process is handled by a specific function called the scheduler.

Agent states

During the simulation an agent can be in three possible states :

• :idle, in which case it is waiting for something to appear in its input tray
• :waiting-for-answer, when it has spawned subtasks and is waiting for some answer
• :busy, when it is processing a task, but is not waiting for subtasks answers.

Simulation Algorithm

The simulation is done in cycles as follows:

The clock starts at time 0. A cycle has 2 steps:

Step 1

Each agent is checked for possible terminating tasks. I.e., the scheduler examines messages stored in the delayed-ouput queue to check if time has come to send them to their target. The qualified messages are moved to the output tray (:output-messages).

Each agent is then examined in turn and messages in the output tray are sent to their target.

Step 2

Agents are checked for possible waiting tasks. A waiting task corresponds to a message in the input tray (:input-messages). How the input messages are taken into account depends on the status of the agent:

• If the agent is busy, then we just ignore keep the message to be processed later;
• if the agent is waiting for an answer of a sub-task it has spawned, then it will respond only to such an answer;
• if the agent is idle, then it will process any available message.

Whenever a new message is taken into account the global number of pending tasks is increased by one. If a task terminates either right away (atomic task), or after all subtasks have been processed, then the number of global pending subtasks is unchanged or decreased by one.

When a task terminates, the resulting output message is not sent right away. It is put into the delayed-output tray, in order to take into account the simulated length of the job. I.e., the message containing the result has a time stamp giving the time at which it must be sent. Thus, it is stored in the delayed-output slot until the specified time is reached by the system clock.

After each cycle the system clock is advanced by 1 unit, and a new cycle starts.

Processing a request

To process a new request message we activate the static function part of the invoqued skill. If the agent does not have the required skill, then this is a fatal error (so far). The static part of the required skill can execute entirely locally, in which case a result will be ready to be sent. In this case the corresponding message is put into the delayed output tray and the agent status is set to busy. Alternatively, the agent may have to call for help from other agents, in which case it builds up subtasks and prepares messages to be sent to other agents (inserted into the delayed output tray). In that case the agent moves to the waiting-for-answer status rather than the busy status.

Processing an answer from a subtask

When the agent is in a waiting-for-answer state, then it looks into the input tray to see if there is any message of answer type. If there is one corresponding to one of the spawned subtasks, then the agent processes it. Afterwards, if there are no more pending tasks, the agent exits by calling dynamic-exit, otherwise it goes back to sleep, waiting for more answers.

Halting condition

When after a given cycle there are no more pending tasks the clock is stopped and a message asks the user of the simulation what she wants to do next.

Copyrignt Jean-Paul Barthès@UTC, 1998 Last update, Jan 99