Multi-threading and multiple FMU instances

[d-model]

On the topic of thread-safety, the fmi standard (in both versions 2 and 3) only has the following to say: "FMI functions of one instance are not required to be thread-safe" (in addition to forbidding changes to global settings). No mention is made of the behaviour of functions on different instances.

In another discussion I saw that the following requirement was at least considered at some point: "Instances of the same FMU and instances of different FMUs must not influence each other", however I have not found it in the standard anywhere. My question is whether this requirement somehow follows from another part of the standard or whether there is a good reason that it was left out of the standard. Not being able to assume this severely limits how a simulation environment can use multi-threading to evaluate model equations.

[Tc-Fast]

From FMI3, 2.2.1. Requirements for Implementations of the C-API

The functions the FMU provides must not change global settings which affect the overall process and/or thread environment:

• For example, an FMU function must not change the current working directory of the process, since this is by definition visible outside of the current execution thread.
  - Note: FMU funtions can, on the other hand, change the floating point control word of the CPU during their execution, since this is directly tied to the thread of execution. However they must restore the floating point control word before returning, so as to not affect state outside of the current thread of execution.

...

• FMI functions must not change global settings which affect other processes/threads. An FMI function may change settings of the thread in which it is called (such as floating point control registers), provided these changes are restored before leaving the function or before a callback function is called. To prepare the FMU code to run reliably on preemptive systems FMI functions must not change global settings.
  - Note: This property ensures that functions of different FMU instances can be called safely in any order. Additionally, they can be called in parallel provided the functions are called in different processes. If an FMI function changes, for example, the floating point control word of the CPU, it must restore the previous value before return of the function.

From Fmi3 Implementers Guide, 3.8.1. Global State

The functions the FMU provides must not change global settings which affect the overall process and/or thread environment:
For example, an FMU function must not change the current working directory of the process, since this is by definition visible outside of the current execution thread.
FMU funtions can, on the other hand, change the floating point control word of the CPU during their execution, since this is directly tied to the thread of execution. However they must restore the floating point control word before returning, so as to not affect state outside of the current thread of execution.

To my understanding: multi-threaded simulation environments cannot safely parallelize the FMU function calls within a single process.
The only way to make this work is by adding a new capability flag like "canBeCalledFromMultipleThreads".

[pmai]

Note that the only place where it talks about separate processes is in a non-normative paragraph, and it should likely say threads rather than processes there (IMHO, as far as I remember our discussions at the time).

From a practical perspective, the expectation is that once separate instances have been allocated, you can run the computations of those instances in parallel from separate threads, the same as running multiple FMUs. What is not required is the ability to run calls for the same instance in parallel, as that would require a very different API specification.

In practice, we have not run into problems with this approach. FMUs that are not capable of doing this are usually marked as being single-instance only, which moots the point.

That being said, it is hard for the FMI spec to be very specific about this, as it is platform-agnostic, and hence what kind of constraints on parallel-processing are possible really depend also on the execution platform, and the facilities the FMU uses.

We might want to clarify expectations, at least non-normatively, some more in the spec.

[pmai]

BTW, further analysis shows that the current process wording in 2.2.1 was introduced by 6378890, which was a mistake, as the wording does not contradict the first bullet point, as claimed in the commit message, since we are now talking about functions for different instances, whereas the first bullet point talks about functions for one instance. Hence the change was unintentional, I would argue, and should be fixed, as proposed in #2160.