Skip to content

Serialize pending transitions when responding to `ACTOR_STATUS` messages on the application side

Maxwell Pirtle requested to merge maxwellpirtle/simgrid:actor-comms into master

Overview

Motivation

This is the first of several small additions/changes to Mc SimGrid that will be introduced to add support for UDPOR in SimGrid. An important step in this process is adding the ability to query precisely what each enabled actor is about to execute in some state, as UDPOR uses this information to explore the unfolding.

Prior to the changes introduced, the checker did not track information concerning the type of each transition that executed by each actor, but merely only if that actor was enabled or disabled (plus some other state that has stayed the same). However, to efficiently compute the so-called extension set of a configuration under consideration by UDPOR (denoted ex(C)), the computation is specialized for each type of transition. Further, UDPOR relies on the dependence relation to decide which events of ex(C) are "worth" exploring, so the transitions in full are needed (i.e. the types alone are not sufficient).

Changes

Transitions are now serialized and sent to the checker side when the ACTOR_STATUS message is sent by the checker as part of the ACTOR_REPLY message (viz. whenever a new State instance is created by the checker). For each enabled actor, the application serializes the current transition that actor is scheduled to execute (i.e. where each actor is currently "frozen") and places all of the serialized transitions contiguously after the block of actor statuses. This results in only a single addition Channel::send()/Channel::receive() pair. The total payload of the ACTOR_REPLY message can be visualized as follows (where N is the number of actors and M is the number of enabled transitions):

ACTORS_STATUS_REPLY
N copies of `s_mc_message_actors_status_one_t`
 | aid_t aid
 | bool enabled
 | int max_considered
 | int n_transitions   <--- new, determines how
 |__________________ 
M copies of `s_mc_message_simcall_probe_one_t` (roughly the same as `s_mc_message_simcall_execute_answer_t`) 
 | std::array<char, SIMGRID_SERIALIZATION_BUFFER_SIZE> buffer
 |__________________ 

Each actor marks the number of transitions that are enabled for it as part of that actor's status. For transitions with max_considered > 1, an actor will serialize all considerations of that transition, invoking prepare() before each serialization as needed. Once received, the transitions are deserialized and managed by the corresponding ActorState instance.

Note": The assumption here is that if an actor is enabled, then all considerations of that actor are also enabled. If that were not the case, each payload of s_mc_message_simcall_probe_one_t might also need to deliver times_considered to give the checker side more information as to which transitions are enabled. This may be needed important with, e.g. state regeneration, as the information is currently implicit in the ordering of the enabled transitions in ActorState

Performance Considerations

Each State now carries around a copy of all enabled transitions at that state, so we can should expect the memory footprint to grow. Likewise, transitions are serialized and sent for each state construction. This is likely to be the most impactful on performance, as it involves increasing the I/O needed for each new state.

There is the opportunity to allow the application side to send only a single transition during state exploration. Since only a single transition is executed between two consecutive states, it is sufficient to send only what the executed actor is about to run, copying over the previous transitions from the previous state. If you think it would be a worthwhile addition immediately, we can implement it before making other changes.

Merge request reports