64 lines
2.6 KiB
Markdown
64 lines
2.6 KiB
Markdown
# Ovni model
|
|
|
|
The ovni model tracks the state of threads and CPUs and provides the
|
|
basis for other models.
|
|
|
|
## Thread model
|
|
|
|
The thread state is modelled as a finite state machine, depicted below:
|
|
|
|
{: style="width:80%"}
|
|
|
|
All threads begin in the `unknown` state and perform a transition to
|
|
running then the `execute` event (with MCV `OHx`) is received.
|
|
Notice that the runtime thread started the execution **before** emitting
|
|
the execute event, as it is not posible to emit the event at the exact
|
|
moment the thread begins the execution.
|
|
|
|
The asterisk `*` in the transitions states when the event is emitted. If
|
|
appears *before* the transition name, it happens *before* the real
|
|
event. If appears *after* then it is emitted *after* the real event.
|
|
|
|
In the case of the thread beginning the execution, the event is emitted
|
|
*after* the thread begins the execution, so the asterisk appears after.
|
|
|
|
### Cooling and warming states
|
|
|
|
In the Linux kernel, it is generally not possible to switch from a
|
|
thread A to another thread B in a single atomic operation, from
|
|
user-space. The thread A must first wake B and then put itself to sleep.
|
|
But the kernel is free to continue the execution of B instead of just
|
|
executing the last instructions of A so it can stop.
|
|
|
|
This limitation causes a time region at which more than one thread is
|
|
scheduled to the same CPU, which is a property that is generally
|
|
considered an error in parallel runtimes. To avoid this situation, the
|
|
additional states *cooling* and *warming* are introduced.
|
|
|
|
The cooling state indicates that the thread will be put to sleep and may
|
|
temporarily wake another thread in the same CPU. Similarly, the warming
|
|
state indicates that a thread is waking up, but it may be another thread
|
|
in its own CPU for a while.
|
|
|
|
These states allow the emulator to ignore the threads in the cooling and
|
|
warming states when only interested in those in the running state, but
|
|
at the same time allow the developers to identify the real transition
|
|
sequence to explain potential delays.
|
|
|
|
## CPU model
|
|
|
|
The CPU can only execute one thread at a time, and it may have multiple
|
|
threads assigned. When two or more threads are in the execution state,
|
|
the emulator cannot determine which one is really being executed, so it
|
|
will set all the channels to an error state.
|
|
|
|
!!! Caution
|
|
|
|
Multiple threads running in the same CPU typically indicates an
|
|
error of instrumentation or a problem in the runtime.
|
|
|
|
The emulator automatically switches the channels from one thread to
|
|
another when a thread is switched from the CPU. So the different models
|
|
don't need to worry about thread transitions. See the
|
|
[channels](../channels) section for more information.
|