Second, saving the whole accessible memory space could lower the number of
recovery points. However, this approach is very time-consuming and therefore only
suitable if the recovery point interval is large.
Until now, module variables were not covered. However, all write-accessed
module variables must be stored as well and thus included in a recovery procedure
frame. Again, the accessed variables are marked and included by compiler control
flow analysis.
Using resource contexts (see Sect. 11.5), another way of creating recovery points
can be considered. As tasks in a resource group only have access to data in the same
resource group, a recovery point could be created when a message to another task is
sent or a message from another task is received. In this case, the whole memory area
occupied by the context as well as all message parameters (which may not be of
pointer type) is included in the recovery point. This results in a very simple recovery point implementation with a good trade-off between recovery point size and
frequency.
In the case of working tasks that perform long calculations without interaction
with other tasks, a system-generated timer could interrupt the currently ongoing
calculation and create an RP of the currently active context.
If an RPU (see Sect. 8.4) is present in the system, the recovery point storage
could even be done concurrently to the processing, as the language partitions the
memory space and ensures isolation.
One could argue that software isolation is not sufficient, as memory faults could
corrupt memory addresses and thus allow the software to access memory areas
outside the current resource context. A simple range check in the hardware memory
controller could solve this. To the application, only two registers are necessary, one
containing the current lower access boundary, and one the upper access boundary.
Memory accesses outside these boundaries trigger an exception.
Another key point in generating recovery points is the storage of input/output
data. Specifically, drivers that read or write from devices must store the data, so that
it can be replayed accurately. To support this feature, every driver can optionally
provide such a buffer. It is up to the programmer to decide whether it is necessary
and useful to provide these rollback buffers, as they might not be necessary
depending on the use of the device (e.g., logging) or the size of the data that is
required to be stored (e.g., disk accesses).
As an example, incoming sensor data might be important enough and small
enough to be stored for use after a recovery. Of course, the location of this sensor
data must be specially marked and protected, for example, by error detection and
correction codes, so that it is not erased during a recovery.
As accessing a hardware device is usually done via memory-mapped I/O, i.e.,
direct memory access, the compiler cannot automatically extract necessary recovery
means from the language and has thus to completely rely on the programmer.
Utmost care is required during the implementation of such memory-mapped I/O
to guarantee first the correct behavior of the driver and second the correct handling
of recovery point data.
130
8 Recovery Preparation
recovery points. However, this approach is very time-consuming and therefore only
suitable if the recovery point interval is large.
Until now, module variables were not covered. However, all write-accessed
module variables must be stored as well and thus included in a recovery procedure
frame. Again, the accessed variables are marked and included by compiler control
flow analysis.
Using resource contexts (see Sect. 11.5), another way of creating recovery points
can be considered. As tasks in a resource group only have access to data in the same
resource group, a recovery point could be created when a message to another task is
sent or a message from another task is received. In this case, the whole memory area
occupied by the context as well as all message parameters (which may not be of
pointer type) is included in the recovery point. This results in a very simple recovery point implementation with a good trade-off between recovery point size and
frequency.
In the case of working tasks that perform long calculations without interaction
with other tasks, a system-generated timer could interrupt the currently ongoing
calculation and create an RP of the currently active context.
If an RPU (see Sect. 8.4) is present in the system, the recovery point storage
could even be done concurrently to the processing, as the language partitions the
memory space and ensures isolation.
One could argue that software isolation is not sufficient, as memory faults could
corrupt memory addresses and thus allow the software to access memory areas
outside the current resource context. A simple range check in the hardware memory
controller could solve this. To the application, only two registers are necessary, one
containing the current lower access boundary, and one the upper access boundary.
Memory accesses outside these boundaries trigger an exception.
Another key point in generating recovery points is the storage of input/output
data. Specifically, drivers that read or write from devices must store the data, so that
it can be replayed accurately. To support this feature, every driver can optionally
provide such a buffer. It is up to the programmer to decide whether it is necessary
and useful to provide these rollback buffers, as they might not be necessary
depending on the use of the device (e.g., logging) or the size of the data that is
required to be stored (e.g., disk accesses).
As an example, incoming sensor data might be important enough and small
enough to be stored for use after a recovery. Of course, the location of this sensor
data must be specially marked and protected, for example, by error detection and
correction codes, so that it is not erased during a recovery.
As accessing a hardware device is usually done via memory-mapped I/O, i.e.,
direct memory access, the compiler cannot automatically extract necessary recovery
means from the language and has thus to completely rely on the programmer.
Utmost care is required during the implementation of such memory-mapped I/O
to guarantee first the correct behavior of the driver and second the correct handling
of recovery point data.
130
8 Recovery Preparation