On the external concurrency

of current BDI frameworks for MAS

Martina Baiardi, Samuele Burattini, Giovanni Ciatto
Danilo Pianini, Alessandro Ricci, and Andrea Omicini

Department of Computer Science and Engineering (DISI)
Alma Mater Studiorum — Università di Bologna
Via dell’Università 50, 47522 Cesena (FC), Italy

Context

BDI Agents Programming

• most famous semantics: AgentSpeak(L)

• most famous architecture (see picture)

• several implementations

  • focus on: Astra, GOAL, Jadex, JaKtA,
    Jason, PHIDIAS, SPADE-BDI

Motivation

Insight: the same architecture may be implemented in so many ways
(e.g., w.r.t. concurrency)

• semantics unaffected
• impact on practical properties such as efficiency & reproducibility

Goals

1. Devise concurrency patterns from the state-of-the-practice
2. Classify BDI technologies accordingly

Background

• Agents lifecycle, in general, is a control-loop

  • sense, then deliberate, then act, repeat

• BDI agents are more complex

  • e.g. sense implies collecting percepts, revising beliefs, etc.
  • e.g. deliberate implies selecting plans, updating intentions, etc.

Which concurrency?

We distinguish between internal and external concurrency

Internal concurrency $\approx$ how agents schedule intentions internally

External concurrency $\approx$ how agents’ control-loops are scheduled by the underlying platform

Which concurrency abstractions?

In practice, technological platforms support:

Common concurrency patterns for MAS

• One-Agent-One-Thread ( 1A1T )
• All-Agents-One-Thread ( AA1T )
• All-Agents-One-Event-Loop ( AA1EL )
• All-Agents-One-Executor ( AA1E )
  • With a fixed-size thread pool
  • With a variable-size thread pool

One-Agent-One-Thread ( 1A1T )

All-Agents-One-Thread ( AA1T )

All-Agents-One-Executor ( AA1E )

Allows for various level of granularity:

Different properties w.r.t. fixed or variable amount of worker threads ($N$)

All-Agents-One-Event-Loop (AA1EL) $\equiv$ AA1E with just one thread

One-Agent-One-Process( 1A1P )

Which concurrency abstraction is the most appropriate?

• The selection of an appropriate concurrency model deeply impacts several aspects of the agent programming framework
  • The efficiency of the MAS may improve, but
  • predictability and reproducibility may be affected.
• Capturing and controlling concurrency is crucial,
  and they often are hidden under the framework abstractions

Analysis on BDI frameworks:

Benchmark

!ping.
+!ping <- 
    .revealCurrentThread("intention 1");
    .send(pong, tell, ball);
    !!showThread(2); /* Generates intention 2 */
    .revealCurrentThread("intention 1").
+ball <-
    !!showThread(4); /* Generates intention 4 */
    .revealCurrentThread("intention 3").
+!showThread(X) <- .revealCurrentThread("intention " + X).

+ball[source(X)] <-
    .revealCurrentThread("intention 5");
    .send(X, tell, ball);
    !!showThread(6); /* Generates intention 6 */
    .revealCurrentThread("intention 5").
+!showThread(X) <- .revealCurrentThread("intention " + X).

Results

Legend

• $\equiv$ supported
• $\equiv$ not supported
• $\equiv$ supported in principle,
  but requires the user to implement it

Discussion

Takeaway 1: better for a BDI framework to support multiple concurrency patterns

Takeaway 2: even better for a BDI framework to support concurrency patterns customisability on the user-side

• supporting e.g. comparing perfomance among different concurrency patterns, for the same MAS
• supporting e.g. prioritising determinism over efficiency (AA1T) for testing
• supporting e.g. prioritising indipendence of control flows (1A1T) for I/O-bound tasks

Conclusions

It is necessary to separate BDI architecture from its actual execution

• without impacting the architecture definition
• without necessarily knowing how to program concurrency abstractions
• choosing dynamically which concurrent execution suits the scenario