mandatory to the model-checker. The simcalls, representing actors'
actions, are the transitions of the formal system. Verifying the
system requires to manipulate these transitions explicitly. This also
mandatory to the model-checker. The simcalls, representing actors'
actions, are the transitions of the formal system. Verifying the
system requires to manipulate these transitions explicitly. This also
commonly used by our users.
So, the key ideas here are:
commonly used by our users.
So, the key ideas here are:
Our futures are based on the C++ Concurrency Technical Specification
API, with a few differences:
Our futures are based on the C++ Concurrency Technical Specification
API, with a few differences:
inter-thread synchronization for our futures.
- As the simulation kernel cannot block, `f.wait()` is not meaningful
inter-thread synchronization for our futures.
- As the simulation kernel cannot block, `f.wait()` is not meaningful
simulation kernel and yield the control until the request is
fulfilled. The performance requirements are very high because
the actors usually do an inordinate amount of simcalls during the
simulation kernel and yield the control until the request is
fulfilled. The performance requirements are very high because
the actors usually do an inordinate amount of simcalls during the
As for real syscalls, the basic idea is to write the wanted call and
its arguments in a memory area that is specific to the actor, and
As for real syscalls, the basic idea is to write the wanted call and
its arguments in a memory area that is specific to the actor, and
{
// If we are in the simulation kernel, we take the fast path and
// execute the code directly without simcall
{
// If we are in the simulation kernel, we take the fast path and
// execute the code directly without simcall
// If we are in the application, pass the code to the simulation
// kernel which executes it for us and reports the result:
// If we are in the application, pass the code to the simulation
// kernel which executes it for us and reports the result:
simgrid::xbt::Result<R> result;
simcall_run_kernel([&]{
xbt_assert(SIMIX_is_maestro(), "Not in maestro");
simgrid::xbt::Result<R> result;
simcall_run_kernel([&]{
xbt_assert(SIMIX_is_maestro(), "Not in maestro");
- simgrid::surf::HostImpl* surf_host =
- this->extension<simgrid::surf::HostImpl>();
- return surf_host->getProperties();
+ simgrid::kernel::resource::HostImpl* host =
+ this->extension<simgrid::kernel::resource::HostImpl>();
+ return host->getProperties();
simgrid::xbt::Result<T> result;
simcall_run_blocking([&result, self, &code]{
simgrid::xbt::Result<T> result;
simcall_run_blocking([&result, self, &code]{
simgrid::xbt::Result<T> result;
simcall_run_blocking([this, &result, self]{
try {
simgrid::xbt::Result<T> result;
simcall_run_blocking([this, &result, self]{
try {
In addition, we wrote variations of some other C++ standard library
classes (`SimulationClock`, `Mutex`, `ConditionVariable`) which work in
the simulation:
In addition, we wrote variations of some other C++ standard library
classes (`SimulationClock`, `Mutex`, `ConditionVariable`) which work in
the simulation:
This type of approach might be useful for other libraries which define
their own contexts. An example of this is
This type of approach might be useful for other libraries which define
their own contexts. An example of this is
(cooperative scheduling): it implements cooperative/fiber
[mutex](https://github.com/mozy/mordor/blob/4803b6343aee531bfc3588ffc26a0d0fdf14b274/mordor/fibersynchronization.h#L70),
[recursive
(cooperative scheduling): it implements cooperative/fiber
[mutex](https://github.com/mozy/mordor/blob/4803b6343aee531bfc3588ffc26a0d0fdf14b274/mordor/fibersynchronization.h#L70),
[recursive