--- /dev/null
+name: Git builds
+
+# This workflow uses actions that are not certified by GitHub.
+# They are provided by a third-party and are governed by
+# separate terms of service, privacy policy, and support
+# documentation.
+
+# Only trigger manually
+on: workflow_dispatch
+
+jobs:
+ simgrid-regular-ubuntu:
+ runs-on: ${{ matrix.config.os }}-latest
+ strategy:
+ matrix:
+ config:
+ - { name: "Ubuntu gcc", os: ubuntu, cc: "gcc", cxx: "g++", generator: "Unix Makefiles", cmake_extra_options: "-DLTO_EXTRA_FLAG=auto" }
+ - { name: "MacOS clang", os: macos, cc: "clang", cxx: "clang++", generator: "Unix Makefiles", cmake_extra_options: "-DLTO_EXTRA_FLAG=auto" }
+ permissions:
+ contents: read
+ packages: write
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v2
+ - name: Init options
+ run: |
+ echo "CC=${{ matrix.config.cc }}" >> $GITHUB_ENV
+ echo "CXX=${{ matrix.config.cxx }}" >> GITHUB_ENV
+ - name: prepare for ubuntu
+ if: matrix.config.os == 'ubuntu'
+ run: |
+ sudo apt-get update && sudo apt-get install ninja-build libboost-dev libboost-context-dev pybind11-dev
+ - name: prepare for macos
+ if: matrix.config.os == 'macos'
+ run: brew install boost eigen pybind11 ninja
+ - name: build
+ run: |
+ mkdir build ; cd build
+ cmake -GNinja -Denable_debug=ON -Denable_documentation=OFF -Denable_coverage=OFF \
+ -Denable_compile_optimizations=ON -Denable_compile_warnings=ON \
+ -Denable_model-checking=OFF -Denable_smpi_MBI_testsuite=OFF \
+ -Denable_smpi=ON -Denable_smpi_MPICH3_testsuite=ON \
+ -DCMAKE_DISABLE_SOURCE_CHANGES=ON -DLTO_EXTRA_FLAG="auto" ..
+ ninja tests
+ ctest --output-on-failure -j$(nproc)
+ - name: Create the failure Message
+ if: ${{ failure() }}
+ run: |
+ ver=$(grep set.SIMGRID_VERSION_MINOR CMakeLists.txt|sed 's/[^"]*"//'|sed 's/".*$//') echo "{\"attachments\": [{\"color\": \"#FF0000\", \"text\":\"Failure when building simgrid on ${{ matrix.config.name }}! See ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }} \"}]}" > mattermost.json
+ - name: Create the success Message
+ if: ${{ success() }}
+ run: |
+ ver=$(grep set.SIMGRID_VERSION_MINOR CMakeLists.txt|sed 's/[^"]*"//'|sed 's/".*$//') echo "{\"attachments\": [{\"color\": \"#00FF00\", \"text\":\"Simgrid built successfully on ${{ matrix.config.name }}! ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }} \"}]}" > mattermost.json
+ - uses: komarnitskyi/action-mattermost-notification@v0.1.2-beta
+ if: ${{ always() }}
+ env:
+ webhook: ${{ secrets.MATTERMOST_WEBHOOK_URL }}
+ channel: ${{ secrets.MATTERMOST_CHANNEL}}
+ json: mattermost.json
+
+ simgrid-modelcheck-ubuntu:
+
+ runs-on: ubuntu-latest
+ permissions:
+ contents: read
+ packages: write
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v2
+
+ - name: build
+ run: |
+ sudo apt-get update && sudo apt-get install ninja-build libboost-dev libboost-context-dev pybind11-dev
+ sudo apt-get install libunwind-dev libdw-dev libelf-dev libevent-dev
+ mkdir build ; cd build
+ cmake -GNinja -Denable_debug=ON -Denable_documentation=OFF -Denable_coverage=OFF \
+ -Denable_compile_optimizations=ON -Denable_compile_warnings=ON \
+ -Denable_model-checking=ON -Denable_smpi_MBI_testsuite=OFF \
+ -Denable_smpi=ON -Denable_smpi_MPICH3_testsuite=OFF \
+ -Denable_ns3=OFF \
+ -DCMAKE_DISABLE_SOURCE_CHANGES=ON -DLTO_EXTRA_FLAG="auto" ..
+ ninja tests
+ ctest --output-on-failure -j$(nproc)
+ - name: Create the failure Message
+ if: ${{ failure() }}
+ run: |
+ ver=$(grep set.SIMGRID_VERSION_MINOR CMakeLists.txt|sed 's/[^"]*"//'|sed 's/".*$//') echo "{\"attachments\": [{\"color\": \"#FF0000\", \"text\":\"Failure when building simgrid Modelchecker on ubuntu-stable! See ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }} \"}]}" > mattermost.json
+ - name: Create the success Message
+ if: ${{ success() }}
+ run: |
+ ver=$(grep set.SIMGRID_VERSION_MINOR CMakeLists.txt|sed 's/[^"]*"//'|sed 's/".*$//') echo "{\"attachments\": [{\"color\": \"#00FF00\", \"text\":\"Simgrid Modelchecker built successfully on ubuntu-stable! ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }} \"}]}" > mattermost.json
+ - uses: komarnitskyi/action-mattermost-notification@v0.1.2-beta
+ if: ${{ always() }}
+ env:
+ webhook: ${{ secrets.MATTERMOST_WEBHOOK_URL }}
+ channel: ${{ secrets.MATTERMOST_CHANNEL}}
+ json: mattermost.json
set(libsimgrid_version "${release_version}")
# Basic checks on cmake
-cmake_minimum_required(VERSION 3.5)
-#for lto, to avoid warning (should be removed when switching to requiring cmake >= 3.9)
-if(NOT CMAKE_VERSION VERSION_LESS "3.9")
- cmake_policy(SET CMP0069 NEW)
-endif()
-# once we move >= 3.13, we should use target_link_option in examples/sthread
+cmake_minimum_required(VERSION 3.12)
+# once we move CMake to >= 3.13, we should use target_link_option in examples/sthread
message(STATUS "Cmake version ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}")
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_HOME_DIRECTORY}/tools/cmake/Modules)
endif()
# tesh.py needs python 3 (or the module python-subprocess32 on python2.8+)
-if(CMAKE_VERSION VERSION_LESS "3.12")
- set(PythonInterp_FIND_VERSION 3)
- set(PythonInterp_FIND_VERSION_COUNT 1)
- set(PythonInterp_FIND_VERSION_MAJOR 3)
- include(FindPythonInterp)
- if(NOT PYTHONINTERP_FOUND)
- message(FATAL_ERROR "Please install Python (version 3 or higher) to compile SimGrid.")
- endif()
-else()
- find_package(Python3 COMPONENTS Interpreter Development)
- if(NOT Python3_Interpreter_FOUND)
- message(FATAL_ERROR "Please install Python (version 3 or higher) to compile SimGrid.")
- endif()
- set(PYTHON_EXECUTABLE ${Python3_EXECUTABLE})
+find_package(Python3 COMPONENTS Interpreter)
+if(NOT Python3_Interpreter_FOUND)
+ message(FATAL_ERROR "Please install Python (version 3 or higher) to compile SimGrid.")
endif()
+set(PYTHON_EXECUTABLE ${Python3_EXECUTABLE})
SET(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/lib)
set(pybind11_FOUND OFF)
endif()
endif()
+endif()
- if(NOT PYTHONLIBS_FOUND AND NOT Python3_Development_FOUND)
- message(STATUS "Python libs not found. Turn pybind11 off.")
-
- set(pybind11_FOUND OFF)
- endif()
+find_package(Python3 COMPONENTS Development)
+if(NOT Python3_Development_FOUND OR NOT pybind11_FOUND)
+ message(STATUS "SimGrid Python bindings cannot be built on this system.")
+ set(default_enable_python OFF)
+else()
+ set(default_enable_python ON)
endif()
-option(enable_python "Whether the Python bindings are activated." ${pybind11_FOUND}) # ON by default if dependencies are met
+option(enable_python "Whether the Python bindings are activated." ${default_enable_python}) # ON by default if dependencies are met
if("${CMAKE_SYSTEM}" MATCHES "FreeBSD" AND enable_model-checking AND enable_python)
message(WARNING "FreeBSD + Model-Checking + Python = too much for now. Disabling the Python bindings.")
endif()
if(enable_python)
+ if(NOT Python3_Development_FOUND)
+ message(FATAL_ERROR "Please install the development components of Python (python3-dev on Debian) to build the Python bindings (or disable that option).")
+ endif()
if(pybind11_FOUND)
message(STATUS "Found pybind11.")
if(NOT enable_lto)
MPI:
- New option smpi/barrier-collectives to add a barrier to some collectives
to detect dangerous code that /may/ work on some MPI implems.
+ - New function SMPI_app_instance_start() to easily start a MPI instance in your S4U simulation.
Models:
- Write the section of the manual about models, at least.
.. _design:
-SimGrid's Design Goals
+SimGrid Design Goals
######################
-Any SimGrid simulation comes down to a set of **actors** using some
-**resources** through **activities**. SimGrid provides several kinds of
-resources (link, CPU, disk, and synchronization objects such as mutex
-or semaphores) along with the corresponding activity kinds
-(communication, execution, I/O, lock). SimGrid users provide a
-platform instantiation (list of interconnected resources) and an
+A SimGrid simulation boils down to a set of **actors** that use
+**resources** by performing **activities**. SimGrid provides several kinds of
+resources (link, CPU, disk, and synchronization objects such as mutexes
+and semaphores) along with the corresponding kinds of activities
+(communication, execution, I/O, synchronization). SimGrid users provide a
+platform instantiation (sets of interconnected resources) and an
application (the code executed by actors) along with the actors'
placement on the platform.
-The actors (ie, the user code) can only interact with the platform
-through activities, that are somewhat similar to synchronizations.
-Some are very natural (locking a mutex is a synchronization with the
-other actors using the same mutex) while others activities constitute
-more original synchronization: execution, communication, and I/O have a
-quantitative component that depends on the resources. But still,
-writing some data to disk is seen as a synchronization with the other
-actors using the same disk. When you lock a mutex, you can proceed
-only when that mutex gets unlocked by someone else. Similarly, when you
-do an I/O, you can proceed once the disk delivered enough performance
-to fulfill your demand (along with the concurrent demands of the other
-actors occurring at the same time). Communication activities have both a
-qualitative component (the actual communication starts only when both
-the sender and receiver are ready to proceed) and a quantitative
-component (consuming the communication power of the link resources).
-
-The design of SimGrid is shaped by several design goals:
+The actors (i.e., the user code) can only interact with the platform
+through activities, which are somewhat similar to synchronizations. Some
+are very natural (locking a mutex is a synchronization with the other
+actors that use the same mutex). Others activities implement more atypical
+kinds of synchronization: execution, communication, and I/O have a
+quantitative component that depends on the resources. Regardless, in
+SimGrid writing some data to disk, for instance, is seen as a
+synchronization with the other actors that use the same disk. When you lock
+a mutex, you can proceed only when that mutex gets unlocked by someone
+else. Similarly, when you do an I/O, you can proceed only once the disk
+has delivered enough performance to fulfill your demand (while competing
+with concurrent demands for that same disk made by other actors).
+Communication activities have both a qualitative component (the actual
+communication starts only when both the sender and receiver are ready to
+proceed) and a quantitative component (consuming the communication power of
+the link resources).
+
+The design of SimGrid is driven by several design goals:
- **reproducibility**: re-executing the same simulation must lead to
the exact same outcome, even if it runs on another computer or
- operating system. When possible, this should also be true when you
- use another version of SimGrid.
- - **sweet spot between accuracy and simulation speed**: running a given simulation should be as fast as possible but predict
+ operating system. When possible, this should also be true across different
+ versions of SimGrid.
+ - **sweet spot between simulation accuracy and simulation speed**: running a given simulation should be as fast as possible but predict
correct performance trends (or even provide accurate predictions when correctly calibrated).
- - **versatility**: ability to simulate many kinds of distributed systems
- and resource models. But the simulation should be parsimonious too,
- to not hinder the tool's usability. SimGrid tries to provide sane
+ - **versatility**: ability to simulate many kinds of distributed system and application, while remaining parsimonious so as to not hinder usability. SimGrid tries to provide sane
default settings along with the possibility to augment and modify
- the provided models and their default settings.
- - **scalability**: ability to deal with very large simulations. In the
- number of actors, in the size of the platform, in the number of
- events, or all together.
+ the provided models and their settings for each relevant use case.
+ - **scalability**: ability to deal with very large simulations in terms of the
+ number of actors, the size of the platform, the number of
+ events, or all all the above.
Actors and activities
*********************
-The first crux of the SimGrid design lays in the interaction between
-each actor and the activities. For the sake of reproducibility, the
-actors cannot interact directly with their environment: every
-modification request is serialized through a central component that
-processes them in a reproducible order. For the sake of speed, SimGrid
-is designed as an operating system: the actors issue **simcalls** to a
-simulation kernel that is called **maestro** (because it decides which
-actors can proceed and which ones must wait).
-
-In practice, a SimGrid simulation is a suite of so-called **scheduling
-rounds**, during which all actors that are not currently blocked on a
-simcall get executed. For that, maestro passes the control flow to the
-code of each actor, that are written in either C++, C, Fortran or Python.
-The control flow then returns to the maestro when the actor
-blocks on its next blocking simcall. Note that the time it takes to
-execute the actor code has to be reported to the simulator using
-execution activities. SMPI programs are automatically benchmarked
-while these executions must be manually reported in S4U. The simulated
+At the core of the SimGrid design lies the interactions between actors and
+activities. For the sake of reproducibility, the actors cannot interact
+directly with their environment: every interaction is serialized through a
+central component that processes them in a reproducible order. For the sake
+of speed, SimGrid is designed as an operating system: the actors issue
+**simcalls** (akin to system calls) to a simulation kernel (akin to an OS
+kernel) called the **maestro** that decides which actors can proceed and
+which ones must wait.
+
+A SimGrid simulation proceeds as a sequence of **scheduling
+rounds**. At each round, all actors that are not currently blocked on a
+simcall get executed. This is done by the maestro, which passes the control flow to the
+code of each actor, written by the user in either C++, C, Fortran or Python.
+The control flow is returned to the maestro when the actor
+blocks on its next simcall. If the time it takes to
+execute the actor's code is of import to the simulator, it has to be the object
+of execution activities. SMPI programs are automatically benchmarked, but
+these execution activities must be manually created if using S4U. The simulated
time is discrete in SimGrid and only progresses between scheduling
-rounds, so all events occurring during a given scheduling round occur
-at the exact same simulated timestamp, even if the actors are usually
-executed sequentially on the real platform.
+rounds. So all events occurring during a given scheduling round occur
+at the exact same simulated time, even if the actors are usually
+executed sequentially on a real platform.
.. image:: img/design-scheduling-simulatedtime.svg
:scale: 80%
:align: center
-To modify their environment, the actors issue either **immediate
-simcalls** that take no time in the simulation (e.g.: spawning another
-actor), or **blocking simcalls** that must wait for future events (e.g.:
+To modify their environment actors issue either **immediate
+simcalls** that take no time in the simulation (e.g., spawning another
+actor), or **blocking simcalls** that must wait for future events (e.g.,
mutex locks require the mutex to be unlocked by its owner;
-communications wait for the network to provide enough communication
-performance to fulfill the demand). A given scheduling round is
+communications wait for the network to provide have provided enough communication
+bandwidth to transfer the data). A given scheduling round is
usually composed of several sub-scheduling rounds during which
immediate simcalls are resolved. This ends when all actors are either
terminated or within a blocking simcall. The simulation models are
-then used to compute the time at which the first next simcall
-terminates. The time is advanced to that point, and a new scheduling
-round begins with all actors that got unblocked at that timestamp.
+then used to compute the time at which the first pending simcall
+terminates. Time is advanced to that point, and a new scheduling
+round begins with all actors that became unblocked at that timestamp.
Context switching between the actors and maestro is highly optimized
for the sake of simulation performance. SimGrid provides several
:align: center
For the sake of performance, actors can be executed in parallel using several system threads which execute all actors in
-turn. But in our experience, this rarely leads to any performance improvement because most applications simulated on top of
-SimGrid are fine-grained: it's often not worth simulating actors in parallel because the amount of work of each actor is too
-small. This is because the users tend to abstract away any large computations to efficiently simulate the control flow of their
-application. In addition, parallel simulation puts unpleasant restrictions on the user code, that must be correctly isolated.
+turn. In our experience, however, this rarely leads to significant performance improvement because most applications simulated with
+SimGrid are fine-grained: it's often not worth simulating actors in parallel because the amount of work performed by each actor is too
+small. This is because the users tend to abstract away any large computations to simulate the control flow of their
+application efficiently. In addition, parallel simulation puts restrictions on the user's code.
For example, the existing SMPI implementation cannot be used in parallel yet.
.. image:: img/design-scheduling-parallel.svg
Parsimonious model versatility
******************************
-Another orthogonal crux of the SimGrid design is the parsimonious versatility in modeling. For that, we tend to unify all
-resource and activity kinds. As you have seen, we parallel the classical notion of **computational power** with the more
-original **communication power** and **I/O power**. Asynchronous executions are less common than the asynchronous communications
-that proliferate in MPI but they are still provided for sake of symmetry: they even prove useful to efficiently simulate thread
-pools. SimGrid also provides asynchronous mutex locks for symmetry. The notion of **pstate** was introduced to model the
-stepwise variation of computational speed depending on the DVFS, and was reused to model the bootup and shutdown phases of a
-CPU: the computational speed is 0 at these specific pstates. This pstate notion was extended to represent the fact that the
-bandwidth provided by a wifi link to a given station depends on its signal-noise ratio (SNR).
-
-Further on this line, all provided resource models are very comparable internally. They :ref:`rely on linear inequation systems
-<models-lmm>`, stating for example that the sum of the computational power received by all computation activities located on a
-given CPU cannot overpass the computational power provided by this resource. This extends nicely to multi-resources activities
-such as communications using several links, and also to the so-called parallel tasks (abstract activities representing a
-parallel execution kernel consuming both the communication and computational power of a set of machines) or fluid I/O streams
-(abstract activities representing a data stream from disk to disk through the network). Specific coefficients are added to the
-linear system to reflect how the real resources are shared between concurrent usages. The resulting system is then solved using
-a max-min objective function that maximizes the minimum of all shares allocated to activities. Our experience shows that this
-approach can successfully be used for fast yet accurate simulations of complex phenomena, provided that the model's coefficients
-and constants are carefully :ref:`calibrated <models_calibration>`, i.e. tailored and instantiated to that phenomenon.
+Another main design goal of SimGrid is parsimonious versatility in
+modeling, that is, aiming to simulate very different things using the same
+simulation abstractions. To achieve this goal, the SimGrid implementation
+tends to unify all resource kinds and activity kinds. For instance, the
+classical notion of **computational power** is mirrored for
+**communication power** and **I/O power**. Asynchronous executions are less
+common than the asynchronous communications that proliferate in MPI but
+they are still provided for sake of symmetry: they even prove useful to
+simulate thread pools efficiently. SimGrid also provides asynchronous mutex
+locks for symmetry. The notion of **pstate** was introduced to model the
+step-wise variation of computational speed depending on the DVFS, and was
+reused to model the bootup and shutdown phases of a CPU: the computational
+speed is 0 at these specific pstates. This pstate notion was extended to
+represent the fact that the bandwidth provided by a wifi link to a given
+station depends on its signal-noise ratio (SNR). In summary, simulation
+abstractions are re-used and/or generalized as much as possible to serve a
+wide range of purposes.
+
+Furthermore, all provided resource models are very similar internally. They
+:ref:`rely on linear inequation systems <models-lmm>`, stating for example
+that the sum of the computational power received by all computation
+activities located on a given CPU cannot exceed the computational power
+provided by this CPU. This extends nicely to multi-resources activities
+such as communications that use several links, and also to parallel tasks
+(abstract activities representing a parallel execution kernel that consumes
+both the communication and computational power of a set of machines) or
+fluid I/O streams (abstract activities representing a data stream from disk
+to disk through the network). Specific coefficients are added to the linear
+system to mimic how the resources behavior in the real world. The resulting
+system is then solved using a max-min objective function that maximizes the
+minimum of all shares allocated to activities. Our experience shows that
+this approach can successfully be used for fast yet accurate simulations of
+complex phenomena, provided that the model's coefficients and constants are
+carefully :ref:`calibrated <models_calibration>`, i.e. tailored and
+instantiated to that phenomenon.
Model-checking
**************
-Even if it was not in the original goals of SimGrid, the framework now
+Even if it was not in its original goals, SimGrid now
integrates a full-featured model-checker (dubbed MC or Mc SimGrid)
that can exhaustively explore all execution paths that the application
could experience. Conceptually, Mc SimGrid is built upon the ideas
presented previously. Instead of using the resource models to compute
-the order simcall terminations, it explores every order that is
+the order of simcall terminations, it explores every order that is
causally possible. In a simulation entailing only three concurrent
events (i.e., simcalls) A, B, and C, it will first explore the
-scenario where the activities order is ABC, then the ACB order, then
+scenario where the activities order is ABC, then ACB, then
BAC, then BCA, then CAB and finally CBA. Of course, the number of
scenarios to explore grows exponentially with the number of simcalls
in the simulation. Mc SimGrid leverages reduction techniques to avoid
-re-exploring equivalent traces.
+re-exploring redundant traces.
In practice, Mc SimGrid can be used to verify classical `safety and
liveness properties
<https://en.wikipedia.org/wiki/Partial_order_reduction>`_ and `state
equality <https://hal.inria.fr/hal-01900120/document>`_.
-Mc SimGrid is more experimental than other parts of the framework, such as SMPI that can now be used to run many full-featured
-MPI codes out of the box, but it's constently improving.
+Mc SimGrid is more experimental than other parts of SimGrid, such as SMPI that can now be used to run many full-featured
+MPI codes out of the box, but it's constantly improving.
Installing from the Source
--------------------------
+.. _install_src_deps:
+
Getting the Dependencies
^^^^^^^^^^^^^^^^^^^^^^^^
``ccmake`` provides a nicer graphical interface compared to ``cmake``.
Press ``t`` in ``ccmake`` if you need to see absolutely all
configuration options (e.g., if your Python installation is not standard).
-boost (at least v1.48, v1.59 recommended)
- - On Debian / Ubuntu: ``apt install libboost-dev libboost-context-dev``
+boost mandatory components (at least v1.48, v1.59 recommended)
+ - On Debian / Ubuntu: ``apt install libboost-dev``
- On CentOS / Fedora: ``dnf install boost-devel``
- On macOS with homebrew: ``brew install boost``
+boost recommended components (optional).
+ - boost-context may be used instead of our own fast context switching code which only works on amd64.
+ - boost-stacktrace is used to get nice stacktraces on errors in SimGrid.
+ - On Debian / Ubuntu: ``apt install libboost-context-dev libboost-stacktrace-dev``
+python bindings (optional):
+ - On Debian / Ubuntu: ``apt install pybind11-dev python3-dev``
+Model-checking dependencies (optional)
+ - On Debian / Ubuntu: ``apt install libunwind-dev libdw-dev libelf-dev libevent-dev``
Eigen3 (optional)
- On Debian / Ubuntu: ``apt install libeigen3-dev``
- On CentOS / Fedora: ``dnf install eigen3-devel``
code, but it may fool the debuggers.
enable_model-checking (on/OFF)
- Activates the formal verification mode. This will **hinder
- simulation speed** even when the model checker is not activated at
- run time.
+ Activates the formal verification mode. This will hinder simulation speed even when the model checker is not activated at run
+ time, because some optimizations such as LTO must be disabled at compile time. You need to have the :ref:`required
+ build-dependencies <install_src_deps>` to activate this option.
enable_ns3 (on/OFF)
Activates the ns-3 bindings. See section :ref:`models_ns3`.
What is SimGrid
---------------
-SimGrid is a framework for developing simulators of distributed applications targeting distributed platforms, which can in turn
+SimGrid is a framework for developing simulators of distributed application executions on distributed platforms. It can
be used to prototype, evaluate and compare relevant platform configurations, system designs, and algorithmic approaches.
-Typical Study based on SimGrid
-------------------------------
+What SimGrid allows you to do
+----------------------------
-Here are some questions on which SimGrid is particularly relevant:
+Here are some objectives for which SimGrid is particularly relevant and has been used extensively:
- - **Compare an Application to another**. This is a classical use case for scientists, who use SimGrid to test how their
- contributed solution compares to the existing solutions from the literature.
+ - **Compare designs**. This is a classical use case for researchers/developers, who use SimGrid to assess how their contributed solution (a platform, system, application, and/or algorithm design) compares to existing solutions from the literature.
- - **Design the best [Simulated] Platform for a given Application.** Tweaking the platform file is much easier than building a
- new real platform for testing purposes. SimGrid also allows for the co-design of the platform and the application by
- modifying both of them.
+ - **Design the best [Simulated] Platform for a given Application.** Modifying a platform file use to drive simulations is much easier than building
+ real-world platforms for testing purposes. SimGrid also allows for the co-design of the platform and the application, as both can be modified with little work.
- - **Debug Real Applications**. With real systems, is sometimes difficult to reproduce the exact run leading to the bug that you
- are tracking. With SimGrid, you are *clairvoyant* about your *reproducible experiments*: you can explore every part of the
- system, and your probe will not change the simulated state. It also makes it easy to mock some parts of the real system that
+ - **Debug Real Applications**. With real systems it is often difficult to reproduce the exact run that would lead to a bug that is being tracked.
+ With SimGrid, you are *clairvoyant* about your *reproducible experiments*: you can explore every part of the
+ system, and your exploration will not change the simulated state. It also makes it easy to mock or abstract away parts of the real system that
are not under study.
- - **Formally assess an algorithm**. Inspirated from model checking, this execution mode does not use the performance models to
- determine the application outcome, but instead explore all causally possible outcomes of your application. This exhaustive
- search is perfect to find bugs that are difficult to trigger otherwise, but it will probably not manage to completely cover
- large applications.
+ - **Formally assess an algorithm**. Inspired by model checking, SimGrid provides an execution mode that does not
+ quantify an application's performance behavior, but that instead explores all causally possible outcomes of the application so as to evaluate application correctness. This exhaustive
+ search is ideal for finding bugs that are difficult to trigger experimentally. But because it is exhaustive, there is a limit to the scale of the applications for which it can be used.
-Any SimGrid study entails the following components:
+ Anatomy of a project that uses SimGrid
+---------------------------------------
- - The studied **application**. This can be either a distributed algorithm described in our simple API (either in C++, Python or
- C) or a full-featured real parallel application using for example the MPI interface :ref:`(more info) <application>`.
+Any project that uses SimGrid as its simulation framework comprises the following components:
- - The **simulated platform**. This is a description (in either XML or C++) of a given distributed system (machines, links,
- disks, clusters, etc). SimGrid makes it easy to augment the simulated platform with a dynamic scenario where for example the
- links are slowed down (because of external usage) or the machines fail. You even have support to specify the applicative
- workload that you want to feed to your application :ref:`(more info) <platform>`.
+ - An **application**. An application consists of one or more process that can either implement distributed algorithms described using a simple API (either in C++, Python or
+ C) or be part of a full-featured real parallel application implemented with, for example, the MPI standard :ref:`(more info) <application>`.
- - The application's **deployment description**. To run your application, you have to describe how it should be deployed on the
- simulated platform. You need to specify which process is mapped onto which machine, along with their parameters :ref:`(more
+ - A **simulated platform**. This is a description (in either XML or C++) of a distributed system's hardware (machines, links,
+ disks, clusters, etc). SimGrid makes it straightforward to augment the simulated platform with dynamic behaviors where, for example, the
+ links are slowed down (because of external usage) or the machines fail :ref:`(more info) <platform>`.
+
+ - An application's **deployment description**. To simulate the execution
+ of the application on the platform, they way in which the application is
+ deployed on the platform must be described. This is done by specifying
+ which process is mapped onto which machine :ref:`(more
info) <scenario>`.
- - The **platform models**. They describe how the simulated platform reacts to the activities of the application. For example,
- the models compute the time taken by a given communication on the simulated platform. These models are already included in
- SimGrid, and you only need to pick one and maybe adapt its configuration to get your results :ref:`(more info) <models>`.
+ - **Platform models**. SimGrid implements models that describe how the simulated platform reacts to the simulated activities performed my
+ application processes. SimGrid provides a range of documented models,
+ which the user can select and configure for their particular use case. A
+ big selling point of SimGrid, which sets it apart from its competitors,
+ is that it can accurately model the network contention that results from
+ concurrent communications. :ref:`(more info) <models>`.
+
+
+The above components are put together to run a **simulation experiment**
+that produces **outcomes** (logs, visualization, statistics) that help
+answer the user's research and development **question**. The outcomes
+typically include a timeline of the application execution and information
+about its energy consumption.
-These components are put together to run a **simulation**, that is an experiment or a probe. Simulations produce **outcomes**
-(logs, visualization, or statistical analysis) that help to answer the **question** targeted by your study. It provides
-information on the timing performance and the energy consumption of your application, taking network, CPU and disk resources
-into account by default, and memory can also be modeled. SimGrid differs from many other tools by accurately modeling the contention
-resulting from concurrent network usages.
-We work hard to make SimGrid easy to use, but you should not blindly trust your results and always strive to double-check the
-predictions. Questioning the realism of your results will lead you to better :ref:`calibrate the models <models_calibration>`,
-which is the best way to ensure accurate predictions. Please also refer to the section :ref:`howto_science`.
+We work hard to make SimGrid easy to use, but you should not blindly trust your results and always strive to validate
+the simulation outcomes. Assessing the realism of these outcomes will lead you to better :ref:`calibrate the models <models_calibration>`,
+which is the best way to achieved high simulation accuracy. Please refer to the section :ref:`howto_science`.
Using SimGrid in practice
-------------------------
SimGrid is versatile and can be used in many ways, but the most typical setup is to specify your algorithm as a C++ or Python
program using our API, along with one of the provided XML platform files as shown in the **first tutorial** on
-:ref:`usecase_simalgo`. If your application is already written in MPI, then you are lucky because SimGrid comes with a very good
-support of this communication interface, as explained in our **second tutorial** on :ref:`usecase_smpi`. The **third tutorial** is on
-:ref:`usecase_modelchecking`. Docker images are provided to run these tutorials without installing anything.
+:ref:`usecase_simalgo`. If your application is already written in MPI, then you are in luck because SimGrid comes with MPI support,
+as explained in our **second tutorial** on :ref:`usecase_smpi`. The **third tutorial** is on
+:ref:`usecase_modelchecking`. Docker images are provided to run these tutorials without installing any software, other than Docker, on your machine.
-SimGrid comes with an :ref:`extensive amount of examples <s4u_examples>`, so that you can quick-start your simulator by
+SimGrid comes with :ref:`many examples <s4u_examples>`, so that you can quick-start your simulator by
assembling and modifying some of the provided examples (see :ref:`this section <setup_your_own>` on how to get your own project
to compile with SimGrid). An extensive documentation is available from the left menu bar. If you want to get an idea of how
-SimGrid works to better use it, you can refer to the :ref:`framework design presentation <design>`.
+SimGrid works you can read about its :ref:`design goals <design>`.
SimGrid Success Stories
-----------------------
Scholar). Among them,
`over 500 publications <https://simgrid.org/usages.html>`_
(written by hundreds of individuals) use SimGrid as a scientific
-instrument to conduct their experimental evaluation. These
-numbers do not include the articles contributing to SimGrid.
-This instrument was used in many research communities, such as
+instrument to conduct experimental evaluations. These
+numbers do not include those articles that directly contribute to SimGrid itself.
+SimGrid was used in many research communities, such as
`High-Performance Computing <https://hal.inria.fr/inria-00580599/>`_,
`Cloud Computing <http://dx.doi.org/10.1109/CLOUD.2015.125>`_,
`Workflow Scheduling <http://dl.acm.org/citation.cfm?id=2310096.2310195>`_,
SimGrid can provide high-quality performance predictions. For example,
we determined the speedup achieved by the Tibidabo ARM-based
cluster before its construction
-(`paper <http://hal.inria.fr/hal-00919507>`_). In this case,
-some differences between the prediction and the real timings were due to
-misconfigurations with the real platform. To some extent,
-SimGrid could even be used to debug the real platform :)
+(`paper <http://hal.inria.fr/hal-00919507>`_). Some
+differences between the simulated and the real timings were observed, and
+turned out to be due to
+misconfigurations in the real platform!
+SimGrid can thus even be used to debug a real platform :)
SimGrid is also used to debug, improve, and tune several large
applications.
`BigDFT <http://bigdft.org>`_ (a massively parallel code
-computing the electronic structure of chemical elements developed by
+for computing the electronic structure of chemical elements developed by
the CEA), `StarPU <http://starpu.gforge.inria.fr/>`_ (a
Unified Runtime System for Heterogeneous Multicore Architectures
developed by Inria Bordeaux), and
SimGrid Limits
--------------
-This framework is by no means the holy grail, able to solve
-every problem on Earth.
+SimGrid is by no means the holy grail that is able to solve every conceivable simulation problem.
-**SimGrid scope is limited to distributed systems.** Real-time
-multi-threaded systems are out of this scope. You could probably tweak
-SimGrid for such studies (or the framework could be extended
-in this direction), but another framework specifically targeting such a
-use case would probably be more suited.
+**SimGrid's scope is limited to distributed systems.** Real-time
+multi-threaded systems are out of this scope. You could probably use and/or
+extend SimGrid for this purpose, but another framework that specifically
+targets this use case would probably be more suitable.
**There is currently no support for 5G or LoRa networks**.
-The framework could certainly be improved in this direction, but this
-still has to be done.
-
-**There is no perfect model, only models adapted to your study.** The SimGrid
-models target fast and large studies, and yet they target realistic results. In
-particular, our models abstract away parameters and phenomena that are often
-irrelevant to reality in our context.
-
-SimGrid is obviously not intended for a study of any phenomenon that our
-abstraction removes. Here are some **studies that you should not do with
+SimGrid could certainly be extended with models for these networks, but this
+yet to be done.
+
+**There is no perfect model, only models adapted to your purposes.** SimGrid's
+models were designed to make it possible to run fast and accurate
+simulations of large systems. As a result, the models abstract away many
+parameters and phenomena that are often irrelevant for most use cases in the
+field. This means that SimGrid cannot be used to study any phenomenon that our
+model do not capture. Here are some **phenomena that you currently cannot study with
SimGrid**:
- - Studying the effect of L3 vs. L2 cache effects on your application
- - Comparing kernel schedulers and policies
- - Comparing variants of TCP
+ - Studying the effect of L3 vs. L2 cache effects on your application;
+ - Comparing kernel schedulers and policies;
+ - Comparing variants of TCP;
- Exploring pathological cases where TCP breaks down, resulting in
- abnormal executions.
- - Studying security aspects of your application, in presence of
+ abnormal executions;
+ - Studying security aspects of your application, in the presence of
malicious agents.
.. _models:
-The SimGrid Models
+The SimGrid models
##################
-This page focuses on the **performance models** that compute the duration of :ref:`every activities <S4U_main_concepts>`
-in the simulator depending on the platform characteristics and on the other activities that are currently sharing the
-resources. If you look for other kind of models (such as routing models or compute model), please refer to :ref:`the
+This page focuses on the **performance models** that compute the duration of :ref:`all activities <S4U_main_concepts>`
+throughout the simulation, based on the platform characteristics and on the other activities that concurrently use the
+resources. If you are looking for information on other kinds of models (such as routing models or compute model), please refer to :ref:`the
bottom of this page <models_other>`.
Modeled resources
*****************
-The main objective of SimGrid is to provide timing information for three following kind of resources: network, CPU,
-and disk.
+The primary objective of SimGrid is to provide simulated timing information
+for the usage of three kinds of resources: networks, CPUs, and disks.
-The **network models** have been improved and regularly assessed for almost 20 years. It should be possible to get
-accurate predictions once you properly :ref:`calibrate the models for your settings<models_calibration>`. As detailed
-in the next sections, SimGrid provides several network models. Two plugins can also be used to compute the network
-energy consumption: One for the :ref:`wired networks<plugin_link_energy>`, and another one for the :ref:`Wi-Fi networks
-<plugin_link_energy>`. Some users find :ref:`TCP simulated performance counter-intuitive<understanding_lv08>` at first
-in SimGrid, sometimes because of a misunderstanding of the TCP behavior in real networks.
+The **network models** have been improved and regularly validated for almost 20 years. It should be possible to get
+accurate simulations once you properly :ref:`calibrate the models for your settings<models_calibration>`. As detailed
+in the next sections, SimGrid provides several network models. Two plugins can also be used to compute the energy
+consumption of the network: one for :ref:`wired networks<plugin_link_energy>` and another one for :ref:`Wi-Fi networks
+<plugin_link_energy>`. Note that at first some users find the way in which SimGrid simulates :ref:`TCP performance<understanding_lv08>` to be
+counter-intuitive; in our experience this is due these users misunderstandings the (complex) behavior
+of TCP in real networks.
-The **computing models** are less developed in SimGrid. Through the S4U interface, the user specifies the amount of
+The **CPU models** are less developed in SimGrid. Through the S4U API, the user can specify amounts of
computational work (expressed in FLOPs, for floating point operations) that each computation "consumes", and the model
-simply divides this amount by the host's FLOP rate to compute the duration of this execution. In SMPI, the user code
+simply divides this amount by a CPU's FLOP rate to compute the duration of the computation
+(accounting for number of cores and all concurrent computations with a time-sharing model). In SMPI, the user code
is automatically timed, and the :ref:`computing speed<cfg=smpi/host-speed>` of the host machine is used to evaluate
the corresponding amount of FLOPs. This model should be sufficient for most users, even though assuming a constant FLOP
-rate for each machine remains a crude simplification. In reality, the flops rate varies because of I/O, memory, and
-cache effects. It is somehow possible to :ref:`overcome this simplification<cfg=smpi/comp-adjustment-file>`, but the
+rate for each machine remains a crude simplification (in reality, the FLOP rate varies because of I/O, memory, and
+cache effects). It is possible to :ref:`overcome this simplification<cfg=smpi/comp-adjustment-file>`, but the
required calibration process is rather intricate and not documented yet (feel free to
-:ref:`contact the community<community>` on need).
-In the future, more advanced models may be added but the existing model proved good enough for all experiments done on
-distributed applications during the last two decades. The CPU energy consumption can be computed with the
+:ref:`contact the community<community>`).
+In the future, more advanced models may be added but the existing model have proven good enough
+over the last two decades. The CPU energy consumption can be computed with the
:ref:`relevant plugin<plugin_host_energy>`.
-The **disk models** of SimGrid are more recent than those for the network and computing resources, but they should
-still be correct for most users. `Studies have shown <https://hal.inria.fr/hal-01197128>`_ that they are sensitive
-under some conditions, and a :ref:`calibration process<howto_disk>` is provided. As usual, you probably want to
-double-check their predictions through an appropriate validation campaign.
+The **disk models** in SimGrid have been included more recently than those for networks and CPUs, but they should
+still prove useful to most users. `Studies have shown <https://hal.inria.fr/hal-01197128>`_ that these models are sensitive
+to various conditions, and a :ref:`calibration process<howto_disk>` is provided. As usual, you probably want to
+assess simulation accuracy through an appropriate validation campaign.
.. _models-lmm:
LMM-based Models
****************
-SimGrid aims at the sweet spot between accuracy and simulation speed. About accuracy, our goal is to report correct
-performance trends when comparing competing designs with a minimal burden on the user, while allowing power users to
-fine tune the simulation models for predictions that are within 5% or less of the results on real machines. For
-example, we determined the `speedup achieved by the Tibidabo ARM-based cluster <http://hal.inria.fr/hal-00919507>`_
-before it was even built. About simulation speed, the tool must be fast and scalable enough to study modern IT systems
-at scale. SimGrid was for example used to simulate `a Chord ring involving millions of actors
-<https://hal.inria.fr/inria-00602216>`_ (even though that has not really been more instructive than smaller scale
-simulations for this protocol), or `a qualification run at full-scale of the Stampede supercomputer
+SimGrid aims at the sweet spot between simulation accuracy and simulation speed. In terms of accuracy, the goal is for simulations
+to report correct
+performance trends when comparing competing designs while placing minimal burden on the user. We also want to allow power users to
+fine tune the simulation models to achieve simulation results that are within 5% or less of what would be observed
+on a real platform. For example, we accurately determined the `speedup achieved by the Tibidabo ARM-based cluster <http://hal.inria.fr/hal-00919507>`_
+before it was even built. In terms of simulation speed, the goal it to be fast and scalable enough to allow the study of modern IT systems
+at scale. SimGrid was, for example, used to simulate `a Chord ring with millions of actors
+<https://hal.inria.fr/inria-00602216>`_ (even though results were not really more instructive than those obtained at smaller scales),
+or `a qualification run at full-scale of the Stampede supercomputer
<https://hal.inria.fr/hal-02096571>`_.
-Most of our models are based on a linear max-min solver (LMM), as depicted below. The actors' activities are
+Most SimGrid models are based on a linear max-min solver (LMM), as depicted below. The actors' activities are
represented by actions in the simulation kernel, accounting for both the initial amount of work of the corresponding
-activity (in FLOPs for computing activities or bytes for networking and disk activities), and the currently remaining
+activity (in FLOPs for CPU activities or bytes for network and disk activities), and the currently remaining
amount of work to process.
-At each simulation step, the instantaneous computing and communicating capacity of each action is computed according
-to the model. A set of constraints is used to express for example that the accumulated instantaneous consumption of a
-given resource by a set actions must remain smaller than the nominal capacity speed of that resource. In the example
-below, it is stated that the speed :math:`\varrho_1` of activity 1 plus the speed :math:`\varrho_n`
-of activity :math:`n` must remain smaller than the capacity :math:`C_A` of the corresponding host A.
+At each simulation step, the instantaneous speed for each action is computed according
+to the model. A set of constraints is used to express resource capacity constraints, i.e., that the cumulative instantaneous consumption of a
+given resource by a set actions must remain below the nominal capacity of that resource. In the example
+below, it is stated that the compute speed :math:`\varrho_1` of activity 1 plus the compute speed :math:`\varrho_n`
+of activity :math:`n`, which both run on host A, must remain smaller than that host's total compute speed :math:`C_A`.
.. image:: img/lmm-overview.svg
-There are obviously many valuations of :math:`\varrho_1, \ldots{}, \varrho_n` that respect such as set of constraints.
-SimGrid usually computes the instantaneous speeds according to a Max-Min objective function, that is maximizing the
+There are many valuations of :math:`\varrho_1, \ldots{}, \varrho_n` that must respect sets of constraints.
+SimGrid usually computes the instantaneous speeds according to a Max-Min objective function, that is, maximizing the
minimum over all :math:`\varrho_i`. The coefficients associated to each variable in the inequalities are used to model
some performance effects, such as the fact that TCP tends to favor communications with small RTTs. These coefficients
are computed from both hard-coded values and :ref:`latency and bandwidth factors<cfg=network/latency-factor>` (more
-details on network performance modeling is given in the next section).
+details on network performance modeling are given in the next section).
-Once the instantaneous speeds are computed, the simulation kernel determines what is the earliest terminating action
-from their respective speeds and remaining amounts of work. The simulated time is then updated along with the values
-in the LMM. As some actions have nothing left to do, the corresponding activities thus terminate, which in turn
-unblocks the corresponding actors that can further execute.
+Once the instantaneous speeds are computed for all acttions, the simulation kernel computes the earliest terminating action
+given their respective speeds and remaining amounts of work. The simulated time is then updated along with remaning
+amounts of work. At this point, some actions have no remaining work and are removed from the LMM. The corresponding activities thus terminate, which in turn
+unblocks the corresponding actors that can then continue executing.
-Most of the SimGrid models build upon the LMM solver, that they adapt and configure for their respective usage. For CPU
+Most of the SimGrid models build upon the LMM solver, which they adapt and configure in various ways. For CPU
and disk activities, the LMM-based models are respectively named **Cas01** and **S19**. The existing network models are
described in the next section.
The TCP models
**************
-SimGrid provides several network performance models which compute the time taken by each communication in isolation.
+SimGrid provides several network performance models that compute the time taken by each communication in isolation.
**CM02** is the simplest one. It captures TCP windowing effects, but does not introduce any correction factors. This
-model should be used if you prefer understandable results over realistic ones. **LV08** (the default model) uses
+model should be used if you prefer human-understandable results over realistic ones. **LV08** (the default model) uses
constant factors that are intended to capture common effects such as slow-start, the fact that TCP headers reduce the
*effective* bandwidth, or TCP's ACK messages. **SMPI** uses more advanced factors that also capture the MPI-specific
effects such as the switch between the eager vs. rendez-vous communication modes. You can :ref:`choose the
-model <options_model_select>` on command line, and these models can be :ref:`further configured <options_model>`.
+model <options_model_select>` on via command-line arguments, and each model can be :ref:`further configured <options_model>`.
-The LMM solver is then used as described above to compute the effect of contention on the communication time that is
-computed by the TCP model. For sake of realism, the sharing on saturated links is not necessarily a fair sharing
+The LMM solver is then used as described above to compute the effect of contention on the communication time when using TCP.
+For the sake of realism, the sharing on saturated links is not necessarily a fair sharing
(unless when ``weight-S=0``, in which case the following mechanism is disabled).
-Instead, flows receive an amount of bandwidth somehow inversely proportional to their round trip time. This is modeled
-in the LMM as a priority which depends on the :ref:`weight-S <cfg=network/weight-S>` parameter. More precisely, this
+Instead, flows receive an amount of bandwidth inversely proportional to their round trip time. This is modeled
+in the LMM as a priority that depends on the :ref:`weight-S <cfg=network/weight-S>` parameter. More precisely, this
priority is computed for each flow as :math:`\displaystyle\sum_{l\in links}\left(Lat(l)+\frac{weightS}{Bandwidth(l)}\right)`, i.e., as the sum of the
-latencies of all links traversed by the communication, plus the sum of `weight-S` over the bandwidth of each link on
-the path. Intuitively, this dependency on the bandwidth of the links somehow accounts for the protocol reactivity.
+latencies of all links traversed by the communication, plus the sum of `weight-S` over the bandwidth of each link along
+the path. This dependency on the link bandwidths is for the model to account for the TCP protocol's reactivity.
-Regardless of the used TCP model, the latency is paid beforehand. It is as if the communication only starts after a
-little delay corresponding to the latency. During that time, the communication has no impact on the links (the other
+Regardless of the TCP model in used, the latency is paid beforehand. It is as if the communication only starts after a
+small delay that corresponds to the end-to-end latency. During that time, the communication has no impact on the links (i.e., the other
communications are not slowed down, because there is no contention yet).
-In addition to these LMM-based models, you can use the :ref:`ns-3 simulator as a network model <models_ns3>`. It is much
-more detailed than the pure SimGrid models and thus slower, but it is easier to get more accurate results. Concerning
-the speed, both simulators are linear in the size of their input, but ns-3 has a much larger input in case of large
-steady communications. On the other hand, the SimGrid models must be carefully :ref:`calibrated <models_calibration>` if
-accuracy is really important to your study, while ns-3 models are less demanding with that regard.
+As an alternative to the above LMM-based models, it is possible to use the :ref:`ns-3 simulator as a network model <models_ns3>`. ns-3 performs
+a mushc more detailed, packet-level simulation
+than the above models. As a result is is much slower but will produce more accurate results.
+Both simulators have time complexity that is linear in the size of their input, but ns-3 has a much larger input in case of large communications
+because it considers individual network packets.
+However, the above SimGrid models must be carefully :ref:`calibrated <models_calibration>` if
+achieve very high accuracy is needed, while ns-3 is less demanding in this regard.
.. _understanding_cm02:
====
This is a simple model of TCP performance, where the sender stops sending packets when its TCP window is full. If the
-acknowledgment packets are returned in time to the sender, the TCP window has no impact on the performance that then is
-only limited by the link bandwidth. Otherwise, late acknowledgments will reduce the bandwidth.
+acknowledgment packets are returned in time to the sender, the TCP window has no impact on the performance, which is then
+only limited by link bandwidths. Otherwise, late acknowledgments will reduce the data transfer rate.
SimGrid models this mechanism as follows: :math:`real\_BW = min(physical\_BW, \frac{TCP\_GAMMA}{2\times latency})` The used
-bandwidth is either the physical bandwidth that is configured in the platform, or a value representing the bandwidth
-limit due to late acknowledgments. This value is the maximal TCP window size (noted TCP Gamma in SimGrid) over the
-round-trip time (i.e. twice the one-way latency). The default value of TCP Gamma is 4194304. This can be changed with
+bandwidth is either the physical bandwidth that is configured in the platform, or a value that represents a bandwidth
+limit due to late acknowledgments. This value is the maximal TCP window size (noted TCP Gamma in SimGrid) divided by the
+round-trip time (i.e. twice the one-way latency). The default value of TCP Gamma is 4194304. This value can be changed with
the :ref:`network/TCP-gamma <cfg=network/TCP-gamma>` configuration item.
-If you want to disable this mechanism altogether (to model e.g. UDP or memory movements), you should set TCP-gamma
+If you want to disable this mechanism altogether (e.g.,to model UDP or memory operations), you should set TCP-gamma
to 0. Otherwise, the time it takes to send 10 Gib of data over a 10 Gib/s link that is otherwise unused is computed as
-follows. This is always given by :math:`latency + \frac{size}{bandwidth}`, but the bandwidth to use may be the physical
-one (10Gb/s) or the one induced by the TCP window, depending on the latency.
+:math:`latency + \frac{size}{bandwidth}`, but the bandwidth in the denominator may be the physical
+one (10Gb/s) or the one induced by the TCP window, depending on the latency:
- - If the link latency is 0, the communication obviously takes one second.
+ - If the link latency is 0, the communication, expectedly, takes one second.
- If the link latency is 0.00001s, :math:`\frac{gamma}{2\times lat}=209,715,200,000 \approx 209Gib/s` which is larger than the
- physical bandwidth. So the physical bandwidth is used (you fully use the link) and the communication takes 1.00001s
- - If the link latency is 0.001s, :math:`\frac{gamma}{2\times lat}=2,097,152,000 \approx 2Gib/s`, which is smalled than the
- physical bandwidth. The communication thus fails to fully use the link, and takes about 4.77s.
+ physical bandwidth. So the physical bandwidth is used (the link is fully utilized) and the communication takes 1.00001s
+ - If the link latency is 0.001s, :math:`\frac{gamma}{2\times lat}=2,097,152,000 \approx 2Gib/s`, which is smaller than the
+ physical bandwidth. The communication thus fails to fully utilize the link and takes about 4.77s.
- With a link latency of 0.1s, :math:`gamma/2\times lat \approx 21Mb/s`, so the communication takes about 476.84 + 0.1 seconds!
- - More cases are tested and enforced by the test ``teshsuite/models/cm02-tcpgamma/cm02-tcpgamma.tesh``
+ - More cases are tested and their validity checked by the test ``teshsuite/models/cm02-tcpgamma/cm02-tcpgamma.tesh`` in our test suite.
For more details, please refer to "A Network Model for Simulation of Grid Application" by Henri Casanova and Loris
-Marchal (published in 2002, thus the model name).
+Marchal (published in 2002, hence the model name).
.. _understanding_lv08:
LV08 (default)
==============
-This model builds upon CM02 to model TCP windowing (see above). It also introduces corrections factors for further realism:
+This model builds on CM02 to model TCP windowing (see above). It also introduces corrections factors for further realism:
latency-factor is 13.01, bandwidth-factor is 0.97 while weight-S is 20537. Lets consider the following platform:
.. code-block:: xml
Parallel tasks (L07)
********************
-This model is rather distinct from the other LMM models because it uses another objective function called *bottleneck*.
-This is because this model is intended to be used for parallel tasks that are actions mixing flops and bytes while the
-Max-Min objective function requires that all variables are expressed using the same unit. This is also why in reality,
-we have one LMM system per resource kind in the simulation, but the idea remains similar.
+This model is rather different from the other LMM models because it uses another objective function, which is called *bottleneck*.
+This is because this model is intended to be used for parallel tasks, that is sets of actions that mix flops and bytes, while the
+Max-Min objective function requires that all variables be expressed using the same unit (which is why in the implementation
+we have one LMM system per resource kind).
Use the :ref:`relevant configuration <options_model_select>` to select this model in your simulation.
In SimGrid, WiFi networks are modeled with WiFi zones, where a zone contains the access point of the WiFi network and
the hosts connected to it (called `stations` in the WiFi world). The network inside a WiFi zone is modeled by declaring
a single regular link with a specific attribute. This link is then added to the routes to and from the stations within
-this WiFi zone. The main difference of WiFi networks is that their performance is not determined by some link bandwidth
-and latency but by both the access point WiFi characteristics and the distance between that access point and a given
+this WiFi zone. The main difference of WiFi networks, when compared to wired networks, is that performance is not determined by link bandwidths
+and latencies but by both the access point WiFi characteristics and the distance between that access point and a given
station.
-Such WiFi zones can be used with the LMM-based model or ns-3, and are supposed to behave similarly in both cases.
+In SimGrid, WiFi zones can be used with the LMM-based models or the ns-3-based model.
Declaring a WiFi zone
=====================
The performance of a wifi network is controlled by the three following properties:
* ``mcs`` (`Modulation and Coding Scheme <https://en.wikipedia.org/wiki/Link_adaptation>`_)
- is a property of the WiFi zone. Roughly speaking, it defines the speed at which the access point is exchanging data
- with all the stations. It depends on the access point's model and configuration. Possible values for the MCS can be
+ is a property of the WiFi zone. Roughly speaking, it defines the speed at which the access point exchanges data
+ with all the stations. It depends on the access point's model and configuration. Possible values for mcs can be
found on Wikipedia for example.
|br| By default, ``mcs=3``.
* ``nss`` (Number of Spatial Streams, or `number of antennas <https://en.wikipedia.org/wiki/IEEE_802.11n-2009#Number_of_antennas>`_) is another property of the WiFi zone. It defines the amount of simultaneous data streams that the access
point can sustain. Not all values of MCS and NSS are valid nor compatible (cf. `802.11n standard <https://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates>`_).
|br| By default, ``nss=1``.
- * ``wifi_distance`` is the distance from a station to the access point. Each station can have its own specific value.
- It is thus a property of the stations declared inside the WiFi zone.
+ * ``wifi_distance`` is the distance from a station to the access point. Since each station can have its own specific value
+ it is a property of the stations declared inside the WiFi zone.
|br| By default, ``wifi_distance=10``.
Here is an example of a zone with non-default ``mcs`` and ``nss`` values.
Constant-time model
*******************
-This simplistic network model is one of the few SimGrid network model that is not based on the LMM solver. In this
+This model is one of the few SimGrid network models that is not based on the LMM solver. In this
model, all communication take a constant time (one second by default). It provides the lowest level of realism, but is
-marginally faster and much simpler to understand. This model may reveal interesting if you plan to study abstract
+faster and much simpler to understand. This model may prove interesting though if you plan to study abstract
distributed algorithms such as leader election or causal broadcast.
.. _models_ns3:
ns-3 as a SimGrid model
***********************
-The **ns-3 based model** is the most accurate network model that you can get in SimGrid. It relies on the well-known
-`ns-3 packet-level network simulator <http://www.nsnam.org>`_ to compute every timing information related to the network
-transfers of your simulation. For instance, this may be used to investigate the validity of a simulation. Note that this
-model is much slower than the LMM-based models, because ns-3 simulates the movement of every network packet involved in
-every communication while SimGrid only recomputes the respective instantaneous speeds of the currently ongoing
-communications when one communication starts or stops.
+The **ns-3 based model** is the most accurate network model in SimGrid. It relies on the well-known
+`ns-3 packet-level network simulator <http://www.nsnam.org>`_ to compute full timing information related to network
+transfers. This
+model is much slower than the LMM-based models. This is because ns-3 simulates the movement of every network packet involved in
+every communication, while the LMM-based models only recompute the respective instantaneous speeds of the currently ongoing
+communications when a communication starts or stops.
You need to install ns-3 and recompile SimGrid accordingly to use this model.
The SimGrid/ns-3 binding only contains features that are common to both systems. Not all ns-3 models are available from
SimGrid (only the TCP and WiFi ones are), while not all SimGrid platform files can be used in conjunction with ns-3
-(routes must be of length 1). Also, the platform built in ns-3 from the SimGrid
+(routes must be of length 1). Note also that the platform built in ns-3 from the SimGrid
description is very basic. Finally, communicating from a host to
-itself is forbidden in ns-3, so every such communication completes
-immediately upon startup.
+itself is forbidden in ns-3, so every such communication is simulated to take zero time.
Compiling the ns-3/SimGrid binding
$ cmake . -Denable_ns3=ON -DNS3_HINT=/opt/ns3 # or change the path if needed
-By the end of the configuration, cmake reports whether ns-3 was found,
+cmake will report whether ns-3 was found,
and this information is also available in ``include/simgrid/config.h``
If your local copy defines the variable ``SIMGRID_HAVE_NS3`` to 1, then ns-3
was correctly detected. Otherwise, explore ``CMakeFiles/CMakeOutput.log`` and
Platform files compatibility
----------------------------
-Any route longer than one will be ignored when using ns-3. They are
+Any route with more than one hop will be ignored when using ns-3. They are
harmless, but you still need to connect your hosts using one-hop routes.
The best solution is to add routers to split your route. Here is an
example of an invalid platform:
</zone>
</platform>
-This can be reformulated as follows to make it usable with the ns-3 binding.
+This platform file can be reformulated as follows to make it usable with the ns-3 binding.
There is no direct connection from alice to bob, but that's OK because ns-3
automatically routes from point to point (using
``ns3::Ipv4GlobalRoutingHelper::PopulateRoutingTables``).
Random seed
-----------
-It is possible to define a fixed or random seed to the ns3 random number generator using the config tag.
+It is possible to define a fixed or random seed for ns-3's random number generator using the config tag.
.. code-block:: xml
...
</platform>
-The first property defines that this platform will be used with the ns3 model.
-The second property defines the seed that will be used. Defined to ``time``,
-it will use a random seed, defined to a number it will use this number as
-the seed.
+The first property defines that this platform will be used with the ns-3 model.
+The second property defines the seed that will be used. If defined to ``time``, as done above,
+it will use a random seed.
Limitations
===========
-A ns-3 platform is automatically created from the provided SimGrid
+A ns-3 platform is automatically created based on the provided SimGrid
platform. However, there are some known caveats:
* The default values (e.g., TCP parameters) are the ns-3 default values.
* ns-3 networks are routed using the shortest path algorithm, using ``ns3::Ipv4GlobalRoutingHelper::PopulateRoutingTables``.
- * End hosts cannot have more than one interface card. So, your SimGrid hosts
+ * End hosts cannot have more than one network interface card. So, your SimGrid hosts
should be connected to the platform through only one link. Otherwise, your
SimGrid host will be considered as a router (FIXME: is it still true?).
Our goal is to keep the ns-3 plugin of SimGrid as easy (and hopefully readable)
-as possible. If the current state does not fit your needs, you should modify
-this plugin, and/or create your own plugin from the existing one. If you come up
+as possible. If the current state of development does not fit your needs, you can modify
+this plugin and/or create your own plugin based on the current one. If you come up
with interesting improvements, please contribute them back.
Troubleshooting
Other kind of models
********************
-As for any simulator, models are very important components of the SimGrid toolkit. Several kind of models are used in
-SimGrid beyond the performance models described above:
+Models are key components of SimGrid, as they should be for any simulation framework, and beyond the above performance models
+SimGrid employs other models:
The **routing models** constitute advanced elements of the platform description. This description naturally entails
:ref:`components<platform>` that are very related to the performance models. For instance, determining the execution
> [0.000000] [mc_global/INFO] **************************
> [0.000000] [ker_engine/INFO] 2 actors are still running, waiting for something.
> [0.000000] [ker_engine/INFO] Legend of the following listing: "Actor <pid> (<name>@<host>): <status>"
-> [0.000000] [ker_engine/INFO] Actor 1 (0@node-0.simgrid.org) simcall CommWait(comm_id:1 src:1 dst:-1 mbox:SMPI-2(id:2) srcbuf:1 dstbuf:2 bufsize:4)
-> [0.000000] [ker_engine/INFO] Actor 2 (1@node-1.simgrid.org) simcall CommWait(comm_id:2 src:2 dst:-1 mbox:SMPI-1(id:0) srcbuf:3 dstbuf:2 bufsize:4)
+> [0.000000] [ker_engine/INFO] Actor 1 (0@node-0.simgrid.org) simcall CommWait(comm_id:1 src:1 dst:-1 mbox:SMPI-2(id:2) srcbuf:1 dstbuf:- bufsize:4)
+> [0.000000] [ker_engine/INFO] Actor 2 (1@node-1.simgrid.org) simcall CommWait(comm_id:2 src:2 dst:-1 mbox:SMPI-1(id:0) srcbuf:2 dstbuf:- bufsize:4)
> [0.000000] [mc_global/INFO] Counter-example execution trace:
> [0.000000] [mc_global/INFO] 1: iSend(mbox=2)
> [0.000000] [mc_global/INFO] 2: iSend(mbox=0)
<prop id="instance_id" value="master_mpi"/>
<prop id="rank" value="1"/>
</actor>
- <actor host="Ginette" function="alltoall_mpi">
- <prop id="instance_id" value="alltoall_mpi"/>
- <prop id="rank" value="0"/>
- </actor>
- <actor host="Bourassa" function="alltoall_mpi">
- <prop id="instance_id" value="alltoall_mpi"/>
- <prop id="rank" value="1"/>
- </actor>
- <actor host="Jupiter" function="alltoall_mpi">
- <prop id="instance_id" value="alltoall_mpi"/>
- <prop id="rank" value="2"/>
- </actor>
- <actor host="Fafard" function="alltoall_mpi">
- <prop id="instance_id" value="alltoall_mpi"/>
- <prop id="rank" value="3"/>
- </actor>
</platform>
XBT_INFO("After finalize %d %d", rank, test[0]);
}
-static void alltoall_mpi(int argc, char* argv[])
+static void alltoall_mpi()
{
- MPI_Init(&argc, &argv);
+ MPI_Init();
int rank;
int size;
e.register_function("worker", worker);
// launch two MPI applications as well, one using master_mpi function as main on 2 nodes
SMPI_app_instance_register("master_mpi", master_mpi, 2);
- // the second performing an alltoall on 4 nodes
- SMPI_app_instance_register("alltoall_mpi", alltoall_mpi, 4);
e.load_deployment(argv[2]);
-
+ // the second performing an alltoall on 4 nodes, started directly, not from the deployment file
+ SMPI_app_instance_start("alltoall_mpi", alltoall_mpi,
+ {e.host_by_name_or_null("Ginette"), e.host_by_name_or_null("Bourassa"),
+ e.host_by_name_or_null("Jupiter"), e.host_by_name_or_null("Fafard")});
+
+ // Start a third MPI application, from a S4U actor after a delay of 10 sec
+ simgrid::s4u::Actor::create("launcher", e.host_by_name_or_null("Ginette"), [&e]() {
+ simgrid::s4u::this_actor::sleep_for(10);
+ XBT_INFO("Start another alltoall_mpi instance");
+ SMPI_app_instance_start("alltoall_mpi", alltoall_mpi,
+ {e.host_by_name_or_null("Ginette"), e.host_by_name_or_null("Bourassa"),
+ e.host_by_name_or_null("Jupiter"), e.host_by_name_or_null("Fafard")});
+ });
e.run();
XBT_INFO("Simulation time %g", simgrid::s4u::Engine::get_clock());
> [0.000000] [xbt_cfg/INFO] Configuration change: Set 'smpi/simulate-computation' to 'no'
> [0.000000] [smpi_config/INFO] You did not set the power of the host running the simulation. The timings will certainly not be accurate. Use the option "--cfg=smpi/host-speed:<flops>" to set its value. Check https://simgrid.org/doc/latest/Configuring_SimGrid.html#automatic-benchmarking-of-smpi-code for more information.
> [11.586581] [smpi_masterworkers/INFO] Simulation time 11.5866
-> [Bourassa:alltoall_mpi:(7) 0.000000] [smpi_masterworkers/INFO] alltoall for rank 1
-> [Bourassa:alltoall_mpi:(7) 0.047272] [smpi_masterworkers/INFO] after alltoall 1
+> [Bourassa:alltoall_mpi#1:(7) 0.000000] [smpi_masterworkers/INFO] alltoall for rank 1
+> [Bourassa:alltoall_mpi#1:(7) 0.047272] [smpi_masterworkers/INFO] after alltoall 1
> [Bourassa:master_mpi:(5) 0.000000] [smpi_masterworkers/INFO] here for rank 1
> [Bourassa:master_mpi:(5) 0.017245] [smpi_masterworkers/INFO] After comm 1
> [Bourassa:master_mpi:(5) 0.017245] [smpi_masterworkers/INFO] After finalize 1 0
-> [Fafard:alltoall_mpi:(9) 0.000000] [smpi_masterworkers/INFO] alltoall for rank 3
-> [Fafard:alltoall_mpi:(9) 0.047582] [smpi_masterworkers/INFO] after alltoall 3
-> [Ginette:alltoall_mpi:(6) 0.000000] [smpi_masterworkers/INFO] alltoall for rank 0
-> [Ginette:alltoall_mpi:(6) 0.037258] [smpi_masterworkers/INFO] after alltoall 0
+> [Fafard:alltoall_mpi#3:(9) 0.000000] [smpi_masterworkers/INFO] alltoall for rank 3
+> [Fafard:alltoall_mpi#3:(9) 0.047582] [smpi_masterworkers/INFO] after alltoall 3
+> [Ginette:alltoall_mpi#0:(6) 0.000000] [smpi_masterworkers/INFO] alltoall for rank 0
+> [Ginette:alltoall_mpi#0:(6) 0.037258] [smpi_masterworkers/INFO] after alltoall 0
> [Ginette:master_mpi:(4) 0.000000] [smpi_masterworkers/INFO] After comm 0
> [Ginette:master_mpi:(4) 0.000000] [smpi_masterworkers/INFO] After finalize 0 0
> [Ginette:master_mpi:(4) 0.000000] [smpi_masterworkers/INFO] here for rank 0
> [Ginette:worker:(2) 11.567566] [smpi_masterworkers/INFO] Exiting now.
-> [Jupiter:alltoall_mpi:(8) 0.000000] [smpi_masterworkers/INFO] alltoall for rank 2
-> [Jupiter:alltoall_mpi:(8) 0.047582] [smpi_masterworkers/INFO] after alltoall 2
+> [Jupiter:alltoall_mpi#2:(8) 0.000000] [smpi_masterworkers/INFO] alltoall for rank 2
+> [Jupiter:alltoall_mpi#2:(8) 0.047582] [smpi_masterworkers/INFO] after alltoall 2
> [Jupiter:worker:(3) 11.586581] [smpi_masterworkers/INFO] Exiting now.
> [Tremblay:master:(1) 0.000000] [smpi_masterworkers/INFO] Got 2 workers and 20 tasks to process
> [Tremblay:master:(1) 0.000000] [smpi_masterworkers/INFO] Sending task 0 of 20 to mailbox 'Ginette'
> [Tremblay:master:(1) 8.379411] [smpi_masterworkers/INFO] Sending task 16 of 20 to mailbox 'Ginette'
> [Tremblay:master:(1) 9.365086] [smpi_masterworkers/INFO] Sending task 17 of 20 to mailbox 'Jupiter'
> [Tremblay:master:(1) 9.534241] [smpi_masterworkers/INFO] Sending task 18 of 20 to mailbox 'Ginette'
+> [Ginette:launcher:(10) 10.000000] [smpi_masterworkers/INFO] Start another alltoall_mpi instance
+> [Ginette:alltoall_mpi#0:(11) 10.000000] [smpi_masterworkers/INFO] alltoall for rank 0
+> [Bourassa:alltoall_mpi#1:(12) 10.000000] [smpi_masterworkers/INFO] alltoall for rank 1
+> [Jupiter:alltoall_mpi#2:(13) 10.000000] [smpi_masterworkers/INFO] alltoall for rank 2
+> [Fafard:alltoall_mpi#3:(14) 10.000000] [smpi_masterworkers/INFO] alltoall for rank 3
+> [Ginette:alltoall_mpi#0:(11) 10.036773] [smpi_masterworkers/INFO] after alltoall 0
+> [Bourassa:alltoall_mpi#1:(12) 10.046578] [smpi_masterworkers/INFO] after alltoall 1
+> [Fafard:alltoall_mpi#3:(14) 10.046865] [smpi_masterworkers/INFO] after alltoall 3
+> [Jupiter:alltoall_mpi#2:(13) 10.046865] [smpi_masterworkers/INFO] after alltoall 2
\ No newline at end of file
add_executable (pthread-${x} EXCLUDE_FROM_ALL pthread-${x}.c)
set_target_properties(pthread-${x} PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
target_link_libraries(pthread-${x} PRIVATE Threads::Threads)
- target_link_libraries(pthread-${x} PUBLIC "-Wl,-znorelro -Wl,-znoseparate-code") # TODO: convert to target_link_option once cmake is >3.13
+ target_link_libraries(pthread-${x} PUBLIC "-Wl,-znorelro -Wl,-znoseparate-code") # TODO: convert to target_link_option once CMAKE_VERSION is >3.13
add_dependencies(tests-mc pthread-${x})
ADD_TESH_FACTORIES(pthread-mc-${x} "^thread" --setenv libdir=${CMAKE_BINARY_DIR}/lib --cd ${CMAKE_BINARY_DIR}/examples/sthread ${CMAKE_CURRENT_SOURCE_DIR}/pthread-mc-${x}.tesh)
SG_END_DECL
-/* C++ declarations for shared_malloc and default copy buffer callback */
#ifdef __cplusplus
+XBT_PUBLIC void SMPI_app_instance_start(const char* name, std::function<void()> const& code,
+ std::vector<simgrid::s4u::Host*> const& hosts);
+
+/* This version without parameter is nice to use with SMPI_app_instance_start() */
+XBT_PUBLIC void MPI_Init();
+
+/* C++ declarations for shared_malloc and default copy buffer callback */
XBT_PUBLIC int smpi_is_shared(const void* ptr, std::vector<std::pair<size_t, size_t>>& private_blocks, size_t* offset);
std::vector<std::pair<size_t, size_t>> shift_and_frame_private_blocks(const std::vector<std::pair<size_t, size_t>>& vec,
# Disable some rules on some files
-sonar.issue.ignore.multicriteria=c1,c2a,c2b,c3,c5a,c5b,c6a,c6b,c7,c8,c9,c10a,c10b,c10c,cex1a,cex1b,cex2a,cex2b,cex3,cex4,cxx17a,cxx17b,cxx17c,cxx17d,cxx17e,cxx17f,f1,p1,s1,s2,s3,s4,s5
+sonar.issue.ignore.multicriteria=c1,c2a,c2b,c3,c5a,c5b,c6a,c6b,c7,c8,c9,c10a,c10b,c10c,cex1a,cex1b,cex2a,cex2b,cex3,cex4,cxx17a,cxx17b,cxx17c,cxx17d,cxx17e,cxx17f,cxx17g,f1,p1,s1,s2,s3,s4,s5
# Pointers should not be cast to integral types
# But we need that for smpi and other places
static_cast<kernel::resource::NetworkModel*>(link.get_impl()->get_model())->get_bandwidth_factor() *
link.get_bandwidth());
});
- s4u::NetZone::on_seal_cb([](s4u::NetZone const& /*netzone*/) { currentContainer.pop_back(); });
kernel::routing::NetPoint::on_creation.connect([](kernel::routing::NetPoint const& netpoint) {
if (netpoint.is_router())
new RouterContainer(netpoint.get_name(), currentContainer.back());
set_state(State::RUNNING);
if (not MC_is_active() && not MC_record_replay_is_active()) {
if (get_hosts().size() == 1) {
+ xbt_assert(not flops_amounts_.empty(), "Cannot start Exec: no flops_amount defined.");
if (thread_count_ == 1) {
model_action_ = get_host()->get_cpu()->execution_start(flops_amounts_.front(), bound_);
model_action_->set_sharing_penalty(sharing_penalty_);
void ExecImpl::reset()
{
clear_hosts();
- bytes_amounts_.clear();
- flops_amounts_.clear();
set_start_time(-1.0);
}
/* Semi private template used by the to_string methods of various observer classes */
template <typename A> static std::string ptr_to_id(A* ptr)
{
- static std::unordered_map<A*, std::string> map;
- if (map.find(ptr) == map.end())
- map.insert(std::make_pair(ptr, std::to_string(map.size() + 1)));
- return map[ptr];
+ static std::unordered_map<A*, std::string> map({{nullptr, "-"}});
+ auto [elm, inserted] = map.try_emplace(ptr);
+ if (inserted)
+ elm->second = std::to_string(map.size() - 1);
+ return elm->second;
}
} // namespace simgrid::kernel::actor
xbt_assert(waitpid(pid, &status, WAITPID_CHECKED_FLAGS) == pid && WIFSTOPPED(status) && WSTOPSIG(status) == SIGSTOP,
"Could not wait model-checked process");
- if (not _sg_mc_dot_output_file.get().empty()) {
- dot_output_ = fopen(_sg_mc_dot_output_file.get().c_str(), "w");
- xbt_assert(dot_output_ != nullptr, "Error open dot output file: %s", strerror(errno));
-
- fprintf(dot_output_, "digraph graphname{\n fixedsize=true; rankdir=TB; ranksep=.25; edge [fontsize=12]; node "
- "[fontsize=10, shape=circle,width=.5 ]; graph [resolution=20, fontsize=10];\n");
- }
-
setup_ignore();
errno = 0;
errno);
}
-void ModelChecker::dot_output(const char* fmt, ...)
-{
- if (dot_output_ != nullptr) {
- va_list ap;
- va_start(ap, fmt);
- vfprintf(dot_output_, fmt, ap);
- va_end(ap);
- }
-}
-
static constexpr auto ignored_local_variables = {
std::make_pair("e", "*"),
std::make_pair("_log_ev", "*"),
// From PTRACE_O_TRACEEXIT:
#ifdef __linux__
if (status>>8 == (SIGTRAP | (PTRACE_EVENT_EXIT<<8))) {
- xbt_assert(ptrace(PTRACE_GETEVENTMSG, remote_process_->pid(), 0, &status) != -1, "Could not get exit status");
+ unsigned long eventmsg;
+ xbt_assert(ptrace(PTRACE_GETEVENTMSG, remote_process_->pid(), 0, &eventmsg) != -1, "Could not get exit status");
+ status = static_cast<int>(eventmsg);
if (WIFSIGNALED(status)) {
MC_report_crash(exploration_, status);
this->get_remote_process().terminate();
Transition* ModelChecker::handle_simcall(aid_t aid, int times_considered, bool new_transition)
{
- s_mc_message_simcall_execute_t m;
- memset(&m, 0, sizeof(m));
+ s_mc_message_simcall_execute_t m = {};
m.type = MessageType::SIMCALL_EXECUTE;
m.aid_ = aid;
m.times_considered_ = times_considered;
void ModelChecker::finalize_app(bool terminate_asap)
{
- s_mc_message_int_t m;
- memset(&m, 0, sizeof m);
+ s_mc_message_int_t m = {};
m.type = MessageType::FINALIZE;
m.value = terminate_asap;
xbt_assert(checker_side_.get_channel().send(m) == 0, "Could not ask the app to finalize on need");
*/
class ModelChecker {
CheckerSide checker_side_;
- // This is the parent snapshot of the current state:
- PageStore page_store_{500};
std::unique_ptr<RemoteProcess> remote_process_;
Exploration* exploration_ = nullptr;
- FILE* dot_output_ = nullptr;
-
- unsigned long visited_states_ = 0;
-
public:
ModelChecker(ModelChecker const&) = delete;
ModelChecker& operator=(ModelChecker const&) = delete;
RemoteProcess& get_remote_process() { return *remote_process_; }
Channel& channel() { return checker_side_.get_channel(); }
- PageStore& page_store() { return page_store_; }
void start();
void shutdown();
Exploration* get_exploration() const { return exploration_; }
void set_exploration(Exploration* exploration) { exploration_ = exploration; }
- unsigned long get_visited_states() const { return visited_states_; }
- void inc_visited_states() { visited_states_++; }
-
- void dot_output(const char* fmt, ...) XBT_ATTRIB_PRINTF(2, 3);
- void dot_output_flush()
- {
- if (dot_output_ != nullptr)
- fflush(dot_output_);
- }
- void dot_output_close()
- {
- if (dot_output_ != nullptr)
- fclose(dot_output_);
- }
-
private:
void setup_ignore();
bool handle_message(const char* buffer, ssize_t size);
namespace simgrid::mc {
/** @brief Save the current state */
-VisitedState::VisitedState(unsigned long state_number, unsigned int actor_count)
- : actor_count_(actor_count), num(state_number)
+VisitedState::VisitedState(unsigned long state_number, unsigned int actor_count, RemoteApp& remote_app)
+ : heap_bytes_used_(remote_app.get_remote_process().get_remote_heap_bytes())
+ , actor_count_(actor_count)
+ , num_(state_number)
{
- this->heap_bytes_used = mc_model_checker->get_remote_process().get_remote_heap_bytes();
- this->system_state = std::make_shared<simgrid::mc::Snapshot>(state_number);
+ this->system_state_ = std::make_shared<simgrid::mc::Snapshot>(state_number, remote_app.get_page_store());
}
void VisitedStates::prune()
XBT_DEBUG("Try to remove visited state (maximum number of stored states reached)");
auto min_element = boost::range::min_element(
states_, [](const std::unique_ptr<simgrid::mc::VisitedState>& a,
- const std::unique_ptr<simgrid::mc::VisitedState>& b) { return a->num < b->num; });
+ const std::unique_ptr<simgrid::mc::VisitedState>& b) { return a->num_ < b->num_; });
xbt_assert(min_element != states_.end());
// and drop it:
states_.erase(min_element);
}
/** @brief Checks whether a given state has already been visited by the algorithm. */
-std::unique_ptr<simgrid::mc::VisitedState> VisitedStates::addVisitedState(unsigned long state_number,
- simgrid::mc::State* graph_state)
+std::unique_ptr<simgrid::mc::VisitedState>
+VisitedStates::addVisitedState(unsigned long state_number, simgrid::mc::State* graph_state, RemoteApp& remote_app)
{
- auto new_state = std::make_unique<simgrid::mc::VisitedState>(state_number, graph_state->get_actor_count());
- graph_state->set_system_state(new_state->system_state);
- XBT_DEBUG("Snapshot %p of visited state %ld (exploration stack state %ld)", new_state->system_state.get(),
- new_state->num, graph_state->get_num());
+ auto new_state =
+ std::make_unique<simgrid::mc::VisitedState>(state_number, graph_state->get_actor_count(), remote_app);
+
+ graph_state->set_system_state(new_state->system_state_);
+ XBT_DEBUG("Snapshot %p of visited state %ld (exploration stack state %ld)", new_state->system_state_.get(),
+ new_state->num_, graph_state->get_num());
auto [range_begin, range_end] = boost::range::equal_range(states_, new_state.get(), [](auto const& a, auto const& b) {
- return std::make_pair(a->actor_count_, a->heap_bytes_used) < std::make_pair(b->actor_count_, b->heap_bytes_used);
+ return std::make_pair(a->actor_count_, a->heap_bytes_used_) < std::make_pair(b->actor_count_, b->heap_bytes_used_);
});
for (auto i = range_begin; i != range_end; ++i) {
auto& visited_state = *i;
- if (*visited_state->system_state.get() == *new_state->system_state.get()) {
+ if (*visited_state->system_state_.get() == *new_state->system_state_.get()) {
// The state has been visited:
std::unique_ptr<simgrid::mc::VisitedState> old_state = std::move(visited_state);
- if (old_state->original_num == -1) // I'm the copy of an original process
- new_state->original_num = old_state->num;
+ if (old_state->original_num_ == -1) // I'm the copy of an original process
+ new_state->original_num_ = old_state->num_;
else // I'm the copy of a copy
- new_state->original_num = old_state->original_num;
+ new_state->original_num_ = old_state->original_num_;
- XBT_DEBUG("State %ld already visited ! (equal to state %ld (state %ld in dot_output))", new_state->num,
- old_state->num, new_state->original_num);
+ XBT_DEBUG("State %ld already visited ! (equal to state %ld (state %ld in dot_output))", new_state->num_,
+ old_state->num_, new_state->original_num_);
/* Replace the old state with the new one (with a bigger num)
(when the max number of visited states is reached, the oldest
one is removed according to its number (= with the min number) */
- XBT_DEBUG("Replace visited state %ld with the new visited state %ld", old_state->num, new_state->num);
+ XBT_DEBUG("Replace visited state %ld with the new visited state %ld", old_state->num_, new_state->num_);
visited_state = std::move(new_state);
return old_state;
}
}
- XBT_DEBUG("Insert new visited state %ld (total : %lu)", new_state->num, (unsigned long)states_.size());
+ XBT_DEBUG("Insert new visited state %ld (total : %lu)", new_state->num_, (unsigned long)states_.size());
states_.insert(range_begin, std::move(new_state));
this->prune();
return nullptr;
class XBT_PRIVATE VisitedState {
public:
- std::shared_ptr<simgrid::mc::Snapshot> system_state = nullptr;
- std::size_t heap_bytes_used = 0;
+ std::shared_ptr<simgrid::mc::Snapshot> system_state_ = nullptr;
+ std::size_t heap_bytes_used_ = 0;
int actor_count_;
- long num; // unique id of that state in the storage of all stored IDs
- long original_num = -1; // num field of the VisitedState to which I was declared equal to (used for dot_output)
+ long num_; // unique id of that state in the storage of all stored IDs
+ long original_num_ = -1; // num field of the VisitedState to which I was declared equal to (used for dot_output)
- explicit VisitedState(unsigned long state_number, unsigned int actor_count);
+ explicit VisitedState(unsigned long state_number, unsigned int actor_count, RemoteApp& remote_app);
};
class XBT_PRIVATE VisitedStates {
public:
void clear() { states_.clear(); }
std::unique_ptr<simgrid::mc::VisitedState> addVisitedState(unsigned long state_number,
- simgrid::mc::State* graph_state);
+ simgrid::mc::State* graph_state, RemoteApp& remote_app);
private:
void prune();
/* Take the initial snapshot */
model_checker_->wait_for_requests();
- initial_snapshot_ = std::make_shared<simgrid::mc::Snapshot>(0);
+ initial_snapshot_ = std::make_shared<simgrid::mc::Snapshot>(0, page_store_);
}
RemoteApp::~RemoteApp()
class XBT_PUBLIC RemoteApp {
private:
std::unique_ptr<ModelChecker> model_checker_;
+ PageStore page_store_{500};
std::shared_ptr<simgrid::mc::Snapshot> initial_snapshot_;
// No copy:
/* Get the remote process */
RemoteProcess& get_remote_process() { return model_checker_->get_remote_process(); }
+
+ PageStore& get_page_store() { return page_store_; }
};
} // namespace simgrid::mc
long State::expended_states_ = 0;
-State::State(const RemoteApp& remote_app) : num_(++expended_states_)
+State::State(RemoteApp& remote_app) : num_(++expended_states_)
{
remote_app.get_actors_status(actors_to_run_);
/* Stateful model checking */
- if ((_sg_mc_checkpoint > 0 && (num_ % _sg_mc_checkpoint == 0)) || _sg_mc_termination) {
- system_state_ = std::make_shared<simgrid::mc::Snapshot>(num_);
- }
+ if ((_sg_mc_checkpoint > 0 && (num_ % _sg_mc_checkpoint == 0)) || _sg_mc_termination)
+ system_state_ = std::make_shared<simgrid::mc::Snapshot>(num_, remote_app.get_page_store());
}
-State::State(const RemoteApp& remote_app, const State* previous_state)
+State::State(RemoteApp& remote_app, const State* previous_state)
: default_transition_(std::make_unique<Transition>()), num_(++expended_states_)
{
/* Stateful model checking */
if ((_sg_mc_checkpoint > 0 && (num_ % _sg_mc_checkpoint == 0)) || _sg_mc_termination) {
- system_state_ = std::make_shared<simgrid::mc::Snapshot>(num_);
+ system_state_ = std::make_shared<simgrid::mc::Snapshot>(num_, remote_app.get_page_store());
}
/* For each actor in the previous sleep set, keep it if it is not dependent with current transition.
std::map<aid_t, Transition> sleep_set_;
public:
- explicit State(const RemoteApp& remote_app);
- explicit State(const RemoteApp& remote_app, const State* previous_state);
+ explicit State(RemoteApp& remote_app);
+ explicit State(RemoteApp& remote_app, const State* previous_state);
/* Returns a positive number if there is another transition to pick, or -1 if not */
aid_t next_transition() const;
void DFSExplorer::check_non_termination(const State* current_state)
{
- for (auto state = stack_.rbegin(); state != stack_.rend(); ++state)
- if (*(*state)->get_system_state() == *current_state->get_system_state()) {
- XBT_INFO("Non-progressive cycle: state %ld -> state %ld", (*state)->get_num(), current_state->get_num());
+ for (auto const& state : stack_) {
+ if (*state->get_system_state() == *current_state->get_system_state()) {
+ XBT_INFO("Non-progressive cycle: state %ld -> state %ld", state->get_num(), current_state->get_num());
XBT_INFO("******************************************");
XBT_INFO("*** NON-PROGRESSIVE CYCLE DETECTED ***");
XBT_INFO("******************************************");
throw TerminationError();
}
+ }
}
RecordTrace DFSExplorer::get_record_trace() // override
void DFSExplorer::log_state() // override
{
on_log_state_signal(get_remote_app());
- XBT_INFO("DFS exploration ended. %ld unique states visited; %ld backtracks (%lu transition replays, %lu states "
+ XBT_INFO("DFS exploration ended. %ld unique states visited; %lu backtracks (%lu transition replays, %lu states "
"visited overall)",
- State::get_expanded_states(), backtrack_count_, mc_model_checker->get_visited_states(),
+ State::get_expanded_states(), backtrack_count_, visited_states_count_,
Transition::get_replayed_transitions());
+ Exploration::log_state();
}
void DFSExplorer::run()
XBT_DEBUG("Exploration depth=%zu (state:#%ld; %zu interleaves todo)", stack_.size(), state->get_num(),
state->count_todo());
- mc_model_checker->inc_visited_states();
+ visited_states_count_++;
// Backtrack if we reached the maximum depth
if (stack_.size() > (std::size_t)_sg_mc_max_depth) {
// Backtrack if we are revisiting a state we saw previously
if (visited_state_ != nullptr) {
XBT_DEBUG("State already visited (equal to state %ld), exploration stopped on this path.",
- visited_state_->original_num == -1 ? visited_state_->num : visited_state_->original_num);
+ visited_state_->original_num_ == -1 ? visited_state_->num_ : visited_state_->original_num_);
visited_state_ = nullptr;
this->backtrack();
continue;
}
- if (_sg_mc_sleep_set) {
- XBT_VERB("Sleep set actually containing:");
- for (auto & [aid, transition] : state->get_sleep_set()) {
-
- XBT_VERB(" <%ld,%s>", aid, transition.to_string().c_str());
-
- }
+ if (_sg_mc_sleep_set && XBT_LOG_ISENABLED(mc_dfs, xbt_log_priority_verbose)) {
+ XBT_VERB("Sleep set actually containing:");
+ for (auto& [aid, transition] : state->get_sleep_set())
+ XBT_VERB(" <%ld,%s>", aid, transition.to_string().c_str());
}
+
/* Actually answer the request: let's execute the selected request (MCed does one step) */
state->execute_next(next);
on_transition_execute_signal(state->get_transition(), get_remote_app());
/* If we want sleep set reduction, pass the old state to the new state so it can
* both copy the sleep set and eventually removes things from it locally */
if (_sg_mc_sleep_set)
- next_state = std::make_unique<State>(get_remote_app(), state);
+ next_state = std::make_unique<State>(get_remote_app(), state);
else
- next_state = std::make_unique<State>(get_remote_app());
+ next_state = std::make_unique<State>(get_remote_app());
on_state_creation_signal(next_state.get(), get_remote_app());
/* Check whether we already explored next_state in the past (but only if interested in state-equality reduction) */
if (_sg_mc_max_visited_states > 0)
- visited_state_ = visited_states_.addVisitedState(next_state->get_num(), next_state.get());
+ visited_state_ = visited_states_.addVisitedState(next_state->get_num(), next_state.get(), get_remote_app());
/* If this is a new state (or if we don't care about state-equality reduction) */
if (visited_state_ == nullptr) {
}
}
- mc_model_checker->dot_output("\"%ld\" -> \"%ld\" [%s];\n", state->get_num(), next_state->get_num(),
- state->get_transition()->dot_string().c_str());
+ dot_output("\"%ld\" -> \"%ld\" [%s];\n", state->get_num(), next_state->get_num(),
+ state->get_transition()->dot_string().c_str());
} else
- mc_model_checker->dot_output("\"%ld\" -> \"%ld\" [%s];\n", state->get_num(),
- visited_state_->original_num == -1 ? visited_state_->num
- : visited_state_->original_num,
- state->get_transition()->dot_string().c_str());
+ dot_output("\"%ld\" -> \"%ld\" [%s];\n", state->get_num(),
+ visited_state_->original_num_ == -1 ? visited_state_->num_ : visited_state_->original_num_,
+ state->get_transition()->dot_string().c_str());
stack_.push_back(std::move(next_state));
}
bool found_backtracking_point = false;
while (not stack_.empty() && not found_backtracking_point) {
std::unique_ptr<State> state = std::move(stack_.back());
-
+
stack_.pop_back();
-
- XBT_DEBUG("Marking Transition >>%s<< of process %ld done and adding it to the sleep set", state->get_transition()->to_string().c_str(), state->get_transition()->aid_);
+
+ XBT_DEBUG("Marking Transition >>%s<< of process %ld done and adding it to the sleep set",
+ state->get_transition()->to_string().c_str(), state->get_transition()->aid_);
state->add_sleep_set(state->get_transition()); // Actors are marked done when they are considerd in ActorState
if (reduction_mode_ == ReductionMode::dpor) {
XBT_VERB(" %s (state=%ld)", prev_state->get_transition()->to_string().c_str(), prev_state->get_num());
XBT_VERB(" %s (state=%ld)", state->get_transition()->to_string().c_str(), state->get_num());
- if (prev_state->is_actor_enabled(issuer_id)){
- if (not prev_state->is_actor_done(issuer_id))
- prev_state->mark_todo(issuer_id);
- else
- XBT_DEBUG("Actor %ld is already in done set: no need to explore it again", issuer_id);
- } else {
- XBT_DEBUG("Actor %ld is not enabled: DPOR may be failing. To stay sound, we are marking every enabled transition as todo", issuer_id);
- prev_state->mark_all_enabled_todo();
- }
+ if (prev_state->is_actor_enabled(issuer_id)) {
+ if (not prev_state->is_actor_done(issuer_id))
+ prev_state->mark_todo(issuer_id);
+ else
+ XBT_DEBUG("Actor %ld is already in done set: no need to explore it again", issuer_id);
+ } else {
+ XBT_DEBUG("Actor %ld is not enabled: DPOR may be failing. To stay sound, we are marking every enabled "
+ "transition as todo",
+ issuer_id);
+ prev_state->mark_all_enabled_todo();
+ }
break;
} else {
XBT_VERB("INDEPENDENT Transitions:");
break;
state->get_transition()->replay();
on_transition_replay_signal(state->get_transition(), get_remote_app());
- /* Update statistics */
- mc_model_checker->inc_visited_states();
+ visited_states_count_++;
}
} // If no backtracing point, then the stack is empty and the exploration is over
}
XBT_DECLARE_ENUM_CLASS(ReductionMode, none, dpor);
ReductionMode reduction_mode_;
- long backtrack_count_ = 0;
+ unsigned long backtrack_count_ = 0; // for statistics
+ unsigned long visited_states_count_ = 0; // for statistics
static xbt::signal<void(RemoteApp&)> on_exploration_start_signal;
static xbt::signal<void(RemoteApp&)> on_backtracking_signal;
namespace simgrid::mc {
+static simgrid::config::Flag<std::string> cfg_dot_output_file{
+ "model-check/dot-output", "Name of dot output file corresponding to graph state", ""};
+
Exploration::Exploration(const std::vector<char*>& args) : remote_app_(std::make_unique<RemoteApp>(args))
{
mc_model_checker->set_exploration(this);
+
+ if (not cfg_dot_output_file.get().empty()) {
+ dot_output_ = fopen(cfg_dot_output_file.get().c_str(), "w");
+ xbt_assert(dot_output_ != nullptr, "Error open dot output file: %s", strerror(errno));
+
+ fprintf(dot_output_, "digraph graphname{\n fixedsize=true; rankdir=TB; ranksep=.25; edge [fontsize=12]; node "
+ "[fontsize=10, shape=circle,width=.5 ]; graph [resolution=20, fontsize=10];\n");
+ }
+}
+
+Exploration::~Exploration()
+{
+ if (dot_output_ != nullptr)
+ fclose(dot_output_);
+}
+
+void Exploration::dot_output(const char* fmt, ...)
+{
+ if (dot_output_ != nullptr) {
+ va_list ap;
+ va_start(ap, fmt);
+ vfprintf(dot_output_, fmt, ap);
+ va_end(ap);
+ fflush(dot_output_);
+ }
}
void Exploration::log_state()
{
- if (not _sg_mc_dot_output_file.get().empty()) {
- mc_model_checker->dot_output("}\n");
- mc_model_checker->dot_output_close();
+ if (not cfg_dot_output_file.get().empty()) {
+ dot_output("}\n");
+ fclose(dot_output_);
}
if (getenv("SIMGRID_MC_SYSTEM_STATISTICS")) {
int ret = system("free");
class Exploration : public xbt::Extendable<Exploration> {
std::unique_ptr<RemoteApp> remote_app_;
+ FILE* dot_output_ = nullptr;
+
public:
explicit Exploration(const std::vector<char*>& args);
+ virtual ~Exploration();
// No copy:
Exploration(Exploration const&) = delete;
Exploration& operator=(Exploration const&) = delete;
- virtual ~Exploration() = default;
-
/** Main function of this algorithm */
virtual void run() = 0;
virtual void log_state();
RemoteApp& get_remote_app() { return *remote_app_.get(); }
+
+ /** Print something to the dot output file*/
+ void dot_output(const char* fmt, ...) XBT_ATTRIB_PRINTF(2, 3);
};
// External constructors so that the types (and the types of their content) remain hidden
namespace simgrid::mc {
VisitedPair::VisitedPair(int pair_num, xbt_automaton_state_t prop_state,
- std::shared_ptr<const std::vector<int>> atomic_propositions, std::shared_ptr<State> app_state)
+ std::shared_ptr<const std::vector<int>> atomic_propositions, std::shared_ptr<State> app_state,
+ RemoteApp& remote_app)
: num(pair_num), prop_state_(prop_state)
{
this->app_state_ = std::move(app_state);
if (not this->app_state_->get_system_state())
- this->app_state_->set_system_state(std::make_shared<Snapshot>(pair_num));
+ this->app_state_->set_system_state(std::make_shared<Snapshot>(pair_num, remote_app.get_page_store()));
this->heap_bytes_used = mc_model_checker->get_remote_process().get_remote_heap_bytes();
this->actor_count_ = app_state_->get_actor_count();
this->other_num = -1;
std::shared_ptr<VisitedPair> LivenessChecker::insert_acceptance_pair(simgrid::mc::Pair* pair)
{
- auto new_pair =
- std::make_shared<VisitedPair>(pair->num, pair->prop_state_, pair->atomic_propositions, pair->app_state_);
+ auto new_pair = std::make_shared<VisitedPair>(pair->num, pair->prop_state_, pair->atomic_propositions,
+ pair->app_state_, get_remote_app());
auto [res_begin,
res_end] = boost::range::equal_range(acceptance_pairs_, new_pair.get(), [](auto const& a, auto const& b) {
continue;
XBT_INFO("Pair %d already reached (equal to pair %d) !", new_pair->num, pair_test->num);
exploration_stack_.pop_back();
- mc_model_checker->dot_output("\"%d\" -> \"%d\" [%s];\n", this->previous_pair_, pair_test->num,
- this->previous_request_.c_str());
+ dot_output("\"%d\" -> \"%d\" [%s];\n", this->previous_pair_, pair_test->num, this->previous_request_.c_str());
return nullptr;
}
return -1;
if (visited_pair == nullptr)
- visited_pair =
- std::make_shared<VisitedPair>(pair->num, pair->prop_state_, pair->atomic_propositions, pair->app_state_);
+ visited_pair = std::make_shared<VisitedPair>(pair->num, pair->prop_state_, pair->atomic_propositions,
+ pair->app_state_, get_remote_app());
auto [range_begin,
range_end] = boost::range::equal_range(visited_pairs_, visited_pair.get(), [](auto const& a, auto const& b) {
if (not current_pair->exploration_started) {
int visited_num = this->insert_visited_pair(reached_pair, current_pair.get());
if (visited_num != -1) {
- mc_model_checker->dot_output("\"%d\" -> \"%d\" [%s];\n", this->previous_pair_, visited_num,
- this->previous_request_.c_str());
- mc_model_checker->dot_output_flush();
+ dot_output("\"%d\" -> \"%d\" [%s];\n", this->previous_pair_, visited_num, this->previous_request_.c_str());
XBT_DEBUG("Pair already visited (equal to pair %d), exploration on the current path stopped.", visited_num);
current_pair->requests = 0;
/* Update the dot output */
if (this->previous_pair_ != 0 && this->previous_pair_ != current_pair->num) {
- mc_model_checker->dot_output("\"%d\" -> \"%d\" [%s];\n", this->previous_pair_, current_pair->num,
- this->previous_request_.c_str());
+ dot_output("\"%d\" -> \"%d\" [%s];\n", this->previous_pair_, current_pair->num, this->previous_request_.c_str());
this->previous_request_.clear();
}
this->previous_pair_ = current_pair->num;
this->previous_request_ = current_pair->app_state_->get_transition()->dot_string();
if (current_pair->search_cycle)
- mc_model_checker->dot_output("%d [shape=doublecircle];\n", current_pair->num);
- mc_model_checker->dot_output_flush();
+ dot_output("%d [shape=doublecircle];\n", current_pair->num);
if (not current_pair->exploration_started)
visited_pairs_count_++;
int actor_count_;
VisitedPair(int pair_num, xbt_automaton_state_t prop_state,
- std::shared_ptr<const std::vector<int>> atomic_propositions, std::shared_ptr<State> app_state);
+ std::shared_ptr<const std::vector<int>> atomic_propositions, std::shared_ptr<State> app_state,
+ RemoteApp& remote_app);
};
class XBT_PRIVATE LivenessChecker : public Exploration {
_sg_mc_max_visited_states = value;
}};
-simgrid::config::Flag<std::string> _sg_mc_dot_output_file{
- "model-check/dot-output",
- "Name of dot output file corresponding to graph state",
- "",
- [](const std::string&) { _mc_cfg_cb_check("file name for a dot output of graph state"); }};
-
simgrid::config::Flag<bool> _sg_mc_termination{
"model-check/termination", "Whether to enable non progressive cycle detection", false,
[](bool) { _mc_cfg_cb_check("value to enable/disable the detection of non progressive cycles"); }};
#include <cerrno>
#include <cstdio> // setvbuf
#include <cstdlib>
-#include <cstring>
#include <memory>
#include <numeric>
#include <sys/ptrace.h>
xbt_assert(errno == 0 && raise(SIGSTOP) == 0, "Could not wait for the model-checker (errno = %d: %s)", errno,
strerror(errno));
- s_mc_message_initial_addresses_t message{MessageType::INITIAL_ADDRESSES, mmalloc_get_current_heap(),
- kernel::actor::ActorImpl::get_maxpid_addr()};
+ s_mc_message_initial_addresses_t message = {};
+ message.type = MessageType::INITIAL_ADDRESSES;
+ message.mmalloc_default_mdp = mmalloc_get_current_heap();
+ message.maxpid = kernel::actor::ActorImpl::get_maxpid_addr();
xbt_assert(instance_->channel_.send(message) == 0, "Could not send the initial message with addresses.");
instance_->handle_messages();
engine->display_all_actor_status();
}
// Send result:
- s_mc_message_int_t answer{MessageType::DEADLOCK_CHECK_REPLY, deadlock};
+ s_mc_message_int_t answer = {};
+ answer.type = MessageType::DEADLOCK_CHECK_REPLY;
+ answer.value = deadlock;
xbt_assert(channel_.send(answer) == 0, "Could not send response");
}
void AppSide::handle_simcall_execute(const s_mc_message_simcall_execute_t* message) const
xbt_assert(channel_.send(MessageType::WAITING) == 0, "Could not send MESSAGE_WAITING to model-checker");
// Finish the RPC from the server: return a serialized observer, to build a Transition on Checker side
- s_mc_message_simcall_execute_answer_t answer;
- memset(&answer, 0, sizeof(answer));
+ s_mc_message_simcall_execute_answer_t answer = {};
answer.type = MessageType::SIMCALL_EXECUTE_ANSWER;
std::stringstream stream;
if (actor->simcall_.observer_ != nullptr) {
i++;
}
- struct s_mc_message_actors_status_answer_t answer {
- MessageType::ACTORS_STATUS_REPLY, num_actors, total_transitions
- };
+ struct s_mc_message_actors_status_answer_t answer = {};
+ answer.type = MessageType::ACTORS_STATUS_REPLY;
+ answer.count = num_actors;
+ answer.transition_count = total_transitions;
xbt_assert(channel_.send(answer) == 0, "Could not send ACTORS_STATUS_REPLY msg");
if (answer.count > 0) {
if (not MC_is_active())
return;
- s_mc_message_ignore_memory_t message;
+ s_mc_message_ignore_memory_t message = {};
message.type = MessageType::IGNORE_MEMORY;
message.addr = (std::uintptr_t)addr;
message.size = size;
const s_xbt_mheap_t* heap = mmalloc_get_current_heap();
- s_mc_message_ignore_heap_t message;
+ s_mc_message_ignore_heap_t message = {};
message.type = MessageType::IGNORE_HEAP;
message.address = address;
message.size = size;
if (not MC_is_active())
return;
- s_mc_message_ignore_memory_t message;
+ s_mc_message_ignore_memory_t message = {};
message.type = MessageType::UNIGNORE_HEAP;
message.addr = (std::uintptr_t)address;
message.size = size;
if (not MC_is_active())
return;
- s_mc_message_register_symbol_t message;
- memset(&message, 0, sizeof(message));
+ s_mc_message_register_symbol_t message = {};
message.type = MessageType::REGISTER_SYMBOL;
xbt_assert(strlen(name) + 1 <= message.name.size(), "Symbol is too long");
strncpy(message.name.data(), name, message.name.size() - 1);
const s_xbt_mheap_t* heap = mmalloc_get_current_heap();
- s_stack_region_t region;
- memset(®ion, 0, sizeof(region));
+ s_stack_region_t region = {};
region.address = stack;
region.context = context;
region.size = size;
region.block = ((char*)stack - (char*)heap->heapbase) / BLOCKSIZE + 1;
- s_mc_message_stack_region_t message;
+ s_mc_message_stack_region_t message = {};
message.type = MessageType::STACK_REGION;
message.stack_region = region;
xbt_assert(channel_.send(message) == 0, "Could not send STACK_REGION to model-checker");
namespace simgrid::mc {
-Region::Region(RegionType region_type, void* start_addr, size_t size)
+Region::Region(PageStore& store, RegionType region_type, void* start_addr, size_t size)
: region_type_(region_type), start_addr_(start_addr), size_(size)
{
xbt_assert((((uintptr_t)start_addr) & (xbt_pagesize - 1)) == 0, "Start address not at the beginning of a page");
- chunks_ = ChunkedData(mc_model_checker->page_store(), mc_model_checker->get_remote_process(),
- RemotePtr<void>(start_addr), mmu::chunk_count(size));
+ chunks_ =
+ ChunkedData(store, mc_model_checker->get_remote_process(), RemotePtr<void>(start_addr), mmu::chunk_count(size));
}
/** @brief Restore a region from a snapshot
ChunkedData chunks_;
public:
- Region(RegionType type, void* start_addr, size_t size);
+ Region(PageStore& store, RegionType type, void* start_addr, size_t size);
Region(Region const&) = delete;
Region& operator=(Region const&) = delete;
Region(Region&& that) = delete;
get_remote_process()->write_bytes(ignored_data.data.data(), ignored_data.data.size(), remote(ignored_data.start));
}
-Snapshot::Snapshot(long num_state, RemoteProcess* process) : AddressSpace(process), num_state_(num_state)
+Snapshot::Snapshot(long num_state, PageStore& store, RemoteProcess* process)
+ : AddressSpace(process), page_store_(store), num_state_(num_state)
{
XBT_DEBUG("Taking snapshot %ld", num_state);
else if (type == RegionType::Heap)
xbt_assert(not object_info, "Unexpected object info for heap region.");
- auto* region = new Region(type, start_addr, size);
+ auto* region = new Region(page_store_, type, start_addr, size);
region->object_info(object_info);
snapshot_regions_.push_back(std::unique_ptr<Region>(region));
}
using hash_type = std::uint64_t;
class XBT_PRIVATE Snapshot final : public AddressSpace {
+ PageStore& page_store_;
+
public:
/* Initialization */
- Snapshot(long num_state, RemoteProcess* process = &mc_model_checker->get_remote_process());
+ Snapshot(long num_state, PageStore& store, RemoteProcess* process = &mc_model_checker->get_remote_process());
/* Regular use */
bool on_heap(const void* address) const
/**************** Class BOOST_tests *************************/
using simgrid::mc::Region;
class snap_test_helper {
+ static simgrid::mc::PageStore page_store_;
+
public:
static void init_memory(void* mem, size_t size);
static void Init();
// static member variables init.
std::unique_ptr<simgrid::mc::RemoteProcess> snap_test_helper::process = nullptr;
+simgrid::mc::PageStore snap_test_helper::page_store_(500);
void snap_test_helper::init_memory(void* mem, size_t size)
{
// Init memory and take snapshots:
init_memory(source, byte_size);
- auto* region0 = new simgrid::mc::Region(simgrid::mc::RegionType::Data, source, byte_size);
+ auto* region0 = new simgrid::mc::Region(page_store_, simgrid::mc::RegionType::Data, source, byte_size);
for (int i = 0; i < n; i += 2) {
init_memory((char*)source + i * xbt_pagesize, xbt_pagesize);
}
- auto* region = new simgrid::mc::Region(simgrid::mc::RegionType::Data, source, byte_size);
+ auto* region = new simgrid::mc::Region(page_store_, simgrid::mc::RegionType::Data, source, byte_size);
void* destination = mmap(nullptr, byte_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
INFO("Could not allocate destination memory");
{
prologue_return ret = prologue(1);
memcpy(ret.src, &mc_model_checker, sizeof(void*));
- const simgrid::mc::Region region2(simgrid::mc::RegionType::Data, ret.src, ret.size);
+ const simgrid::mc::Region region2(page_store_, simgrid::mc::RegionType::Data, ret.src, ret.size);
INFO("Mismtach in MC_region_read_pointer()");
REQUIRE(MC_region_read_pointer(®ion2, ret.src) == mc_model_checker);
XBT_LOG_NEW_DEFAULT_SUBCATEGORY(smpi_mpi, smpi, "Logging specific to SMPI ,(mpi)");
+void MPI_Init()
+{
+ MPI_Init(nullptr, nullptr);
+}
+
#define NOT_YET_IMPLEMENTED \
{ \
xbt_die("Not yet implemented: %s. Please contact the SimGrid team if support is needed", __func__); \
return;
const simgrid::s4u::Actor* self = simgrid::s4u::Actor::self();
- ext->instance_id_ = self->get_property("instance_id");
+ const char* id = self->get_property("instance_id");
+ xbt_assert(id != nullptr, "Actor '%s' seem to be calling MPI_Init(), but it was created outside of MPI, wasn't it?",
+ self->get_cname());
+ ext->instance_id_ = id;
const int rank = static_cast<int>(xbt_str_parse_int(self->get_property("rank"), "Cannot parse rank"));
ext->state_ = SmpiProcessState::INITIALIZING;
# ifndef MAC_OS_X_VERSION_10_12
# define MAC_OS_X_VERSION_10_12 101200
# endif
+# ifndef __MAC_11_0
+# define __MAC_11_0 110000
+# endif
-constexpr bool HAVE_WORKING_MMAP = (MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_12);
+constexpr bool HAVE_WORKING_MMAP = ((MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_12) && (MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_11_0));
#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__sun) || defined(__HAIKU__) || defined(__MUSL__)
constexpr bool HAVE_WORKING_MMAP = false;
#else
smpi_instances.try_emplace(name, num_processes);
}
+void SMPI_app_instance_start(const char* name, const std::function<void()>& code,
+ std::vector<simgrid::s4u::Host*> const& hosts)
+{
+ xbt_assert(not hosts.empty(), "Cannot start a SMPI instance on 0 hosts");
+
+ auto [_, inserted] = smpi_instances.try_emplace(name, hosts.size());
+ xbt_assert(inserted, "Cannot start two MPI applications of the same name '%s'", name);
+
+ int rank = 0;
+ for (auto* host : hosts) {
+ auto rank_str = std::to_string(rank);
+ auto actor = simgrid::s4u::Actor::init(std::string(name) + "#" + rank_str, host);
+ actor->set_property("instance_id", name);
+ actor->set_property("rank", rank_str);
+ actor->start(code);
+
+ smpi_deployment_register_process(name, rank, actor.get());
+
+ rank++;
+ }
+}
void smpi_deployment_register_process(const std::string& instance_id, int rank, const simgrid::s4u::Actor* actor)
{
MPI_Comm* smpi_deployment_comm_world(const std::string& instance_id)
{
- if (smpi_instances
- .empty()) { // no instance registered, we probably used smpirun. (FIXME: I guess this never happens for real)
- return nullptr;
- }
Instance& instance = smpi_instances.at(instance_id);
return &instance.comm_world_;
}
atomicity_ = true;
if (comm_->rank() == 0) {
int size = comm_->size() + FP_SIZE;
- list_ = new char[size];
+ list_ = new char[size]();
errhandler_ = SMPI_default_File_Errhandler;
errhandler_->ref();
- memset(list_, 0, size);
shared_file_pointer_ = new MPI_Offset();
shared_mutex_ = s4u::Mutex::create();
*shared_file_pointer_ = 0;
{
MPI_Request request = irecv(buf, count, datatype, src, tag, comm);
int retval = wait(&request,status);
- request = nullptr;
return retval;
}
if(dst != MPI_PROC_NULL)
request->start();
wait(&request, MPI_STATUS_IGNORE);
- request = nullptr;
}
void Request::send(const void *buf, int count, MPI_Datatype datatype, int dst, int tag, MPI_Comm comm)
if(dst != MPI_PROC_NULL)
request->start();
wait(&request, MPI_STATUS_IGNORE);
- request = nullptr;
}
void Request::ssend(const void *buf, int count, MPI_Datatype datatype, int dst, int tag, MPI_Comm comm)
if(dst != MPI_PROC_NULL)
request->start();
wait(&request,MPI_STATUS_IGNORE);
- request = nullptr;
}
void Request::sendrecv(const void *sendbuf, int sendcount, MPI_Datatype sendtype,int dst, int sendtag,
template <typename Iterator> void powerset_iterator<Iterator>::increment()
{
- if (!current_subset_iter.has_value() || !current_subset_iter_end.has_value(),
+ if (!current_subset_iter.has_value() || !current_subset_iter_end.has_value() ||
!current_subset_iter.has_value() || !iterator_end.has_value()) {
return; // We've traversed all subsets at this point, or we're the "last" iterator
}
set(enable_lto OFF)
if(enable_compile_optimizations
AND (NOT enable_model-checking))
- if(CMAKE_VERSION VERSION_LESS "3.9")
- if ( CMAKE_COMPILER_IS_GNUCC
- AND (CMAKE_C_COMPILER_VERSION VERSION_GREATER "4.8.5")
- AND (LINKER_VERSION VERSION_GREATER "2.22"))
- set(enable_lto ON)
- endif()
- else()
- include(CheckIPOSupported)
- check_ipo_supported(RESULT ipo LANGUAGES C CXX)
- if(ipo)
- set(enable_lto ON)
- endif()
+ include(CheckIPOSupported)
+ check_ipo_supported(RESULT ipo LANGUAGES C CXX)
+ if(ipo)
+ set(enable_lto ON)
endif()
endif()
have_NS3="yes"
fi
fi
-MAY_HINT_AT_NS3=""
-if [ $NODE_NAME = "ubuntu-lts" ] ; then
- MAY_HINT_AT_NS3="-DNS3_HINT=/builds/ns-3-dev/build/"
- have_NS3="yes"
-fi
if [ "$os" = "nixos" ] ; then
have_NS3="yes"
fi
-Denable_compile_warnings=$(onoff test "$GENERATOR" != "MSYS Makefiles") -Denable_smpi=ON \
-Denable_ns3=$(onoff test "$have_NS3" = "yes" -a "$build_mode" = "Debug") \
-DSIMGRID_PYTHON_LIBDIR=${SIMGRID_PYTHON_LIBDIR} \
- -DCMAKE_DISABLE_SOURCE_CHANGES=ON ${MAY_DISABLE_LTO} ${MAY_HINT_AT_NS3} \
+ -DCMAKE_DISABLE_SOURCE_CHANGES=ON ${MAY_DISABLE_LTO} \
-DLTO_EXTRA_FLAG="auto" \
-DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
"$SRCFOLDER"
