Multithreading in agents

Multithreading in standard applications is an area of tricks, traps, and a lot of well-meant but not well-done solutions. And in agent applications, the situation is even more tricky. Yet multithreding is a technique which could turn out to be useful or even required for many of your applications.

The problem

Agents are the only Place Users to be able to change their execution environment during runtime. AMETAS implements the notion of weak migration: An agent always resumes its execution at some predefined location in the code and not after the command that caused the migration. It is up to the implementor to take measures to let the agent resume execution without losing the previously collected data. For example, he could insert an if-else block that determines which code to execute when

1. the agent was just instantiated, or
2. the agent just migrated.

However, what about all the other threads? They could probably do some important job in the background. How do we ensure that nothing is lost when the agent migrates?

Actions in the kernel

When the driver thread reaches go, the AMETAS kernel ungracefully terminates all threads of the agent. This is done by enumerating all threads in the agent's threadgroup and performing a Thread.stop on each of them. Whatever has not been finished, will not be finished.

This thread management works quite flawlessly. But remember the risk of using multiple threads:

It is totally up to the implementor to prevent the interruption of background threads when the agent initiates its migration.

Remember, it's the agent which decides to go. Why should it go before all threads are done with their jobs? That means:

Do not go if you do not want your threads to be interrupted. Go when your threads are done.

Some notes

• All threads may influence each other as long as they belong to the same application. For agents, these are all threads in its threadgroup.
• You cannot choose another threadgroup for your threads.
• You must not call go from another thread than the driver thread. All other threads will receive a MigrationAbortedException.
• If your threads want to access driver methods you must pass a reference to the driver to the threads. You must remove this reference before migration (otherwise the migration will be aborted). It is better practise to create methods in the agent and use these methods to access the driver. Alternatively, you can use the getDriver method of the agent.
• Even though execution seems to proceed by the background threads, you must not kill the driver thread at any time. Once it died, your agent will never be able to migrate again.