Designing X-Agents Using FLAME
57
> cd ~/src/libmbord-0.2.1
> ./configure disable-tests with-mpi=/usr/lib64/mpich
--prefix=HOME/build/libmboard
> make
> make install
3.4.2 FLAME’s Synchronization Points
FLAME produces a state dependency graph for each model that contains
information on function order executing in one iteration. Common parallelization problems occur due to occurrence of deadlocks during execution [43]. A
deadlock occurs when
• A resource is not in mutual exclusion condition, where the resource
cannot be used by more than one process at one time.
• Processes which are holding resources wait for more new resources.
• No resource can be forced to be removed from the process using it, until
released by the process.
• Two or more processes form a circular condition, where one process is
waiting for the second process to release a resource, at the same time
when the second is waiting for the first to finish working with it.
FLAME agents communicate through messages being written and read
via the message board library (Figure 3.11). Using a model description file,
it works out possible synchronization points between functions in both serial
and parallel nodes (Figure 3.10). These points create a function interaction
dependency with the message board library, making sure all information is
homogenized for all agents. This ensures that deadlocks can be prevented
when the model runs on parallel computers.
Figure 3.14 shows how synchronization points are set between messages
being sent and read by functions. At a synchronization point, the message
board for a message list is locked for reading. This allows all agents to send
messages to the message board, before any other agents can start to read
them.
This approach is good for parallel computing, but also prevents agents from
executing any dependent functions until all messages are read. All functions
that involve reading that message board are then scheduled to run after the
function sending the messages has finished. This allows all agents to follow
particular plans and cannot change their behavior during a time step.
If agents need to change their functions, this is done by implementing a rule
database or adding flags to which function to execute. The synchronization
points have to be scheduled around these choice functions. FLAME can also
specify a message range to build local social circles and message filters to
enable neighborhood emergence.
57
> cd ~/src/libmbord-0.2.1
> ./configure disable-tests with-mpi=/usr/lib64/mpich
--prefix=HOME/build/libmboard
> make
> make install
3.4.2 FLAME’s Synchronization Points
FLAME produces a state dependency graph for each model that contains
information on function order executing in one iteration. Common parallelization problems occur due to occurrence of deadlocks during execution [43]. A
deadlock occurs when
• A resource is not in mutual exclusion condition, where the resource
cannot be used by more than one process at one time.
• Processes which are holding resources wait for more new resources.
• No resource can be forced to be removed from the process using it, until
released by the process.
• Two or more processes form a circular condition, where one process is
waiting for the second process to release a resource, at the same time
when the second is waiting for the first to finish working with it.
FLAME agents communicate through messages being written and read
via the message board library (Figure 3.11). Using a model description file,
it works out possible synchronization points between functions in both serial
and parallel nodes (Figure 3.10). These points create a function interaction
dependency with the message board library, making sure all information is
homogenized for all agents. This ensures that deadlocks can be prevented
when the model runs on parallel computers.
Figure 3.14 shows how synchronization points are set between messages
being sent and read by functions. At a synchronization point, the message
board for a message list is locked for reading. This allows all agents to send
messages to the message board, before any other agents can start to read
them.
This approach is good for parallel computing, but also prevents agents from
executing any dependent functions until all messages are read. All functions
that involve reading that message board are then scheduled to run after the
function sending the messages has finished. This allows all agents to follow
particular plans and cannot change their behavior during a time step.
If agents need to change their functions, this is done by implementing a rule
database or adding flags to which function to execute. The synchronization
points have to be scheduled around these choice functions. FLAME can also
specify a message range to build local social circles and message filters to
enable neighborhood emergence.