W
00
t ¼
X n
t¼0
ð1 À l i ÞW s
ð8:7Þ
The saved time is thus linearly depending on the recovery mode and the number
and size of the generated but not stored recovery points.
8.6 Implementation Aspects
In this section, we focus on some aspects that are important for the implementation
of recovery points. As already mentioned, the use of structured languages such as
Pascal or Oberon improves the efficiency as the strong-type safety of the system
allows to statically extract much more information than in other languages such as
C or even assembler.
We present here for every program language structure a possible recovery point
implementation strategy for recovery on the level of procedures and show the
limitations. In Oberon, modules act as formal entities to separate concerns.
Figure 8.5 shows two modules, M1 and M2, where M2 imports the module M1,
i.e., M2 gets access to the exported interface of M1.
As the basis for the discussion, we use Oberon-07 [57] as programming language but remove two language features that simplify the implementation
considerably.
First feature removed is nested procedures as it is difficult to find the accessible
state space of a nested procedure at compile time. Nested procedures do not add
additional functionality to the language but simply provide a nonessential structuring mechanism.
The second feature we remove is the export of read-only module variables.
Again, this helps the compiler to limit the state space and a procedure in a module
can access. Read-only variables can be simulated by wrapping them into exported
procedures.
Under these constraints, the only way of interaction between modules is by
accessing exported procedures. Generating a recovery point at cross-module
Fig. 8.5 Module imports
128
8 Recovery Preparation
00
t ¼
X n
t¼0
ð1 À l i ÞW s
ð8:7Þ
The saved time is thus linearly depending on the recovery mode and the number
and size of the generated but not stored recovery points.
8.6 Implementation Aspects
In this section, we focus on some aspects that are important for the implementation
of recovery points. As already mentioned, the use of structured languages such as
Pascal or Oberon improves the efficiency as the strong-type safety of the system
allows to statically extract much more information than in other languages such as
C or even assembler.
We present here for every program language structure a possible recovery point
implementation strategy for recovery on the level of procedures and show the
limitations. In Oberon, modules act as formal entities to separate concerns.
Figure 8.5 shows two modules, M1 and M2, where M2 imports the module M1,
i.e., M2 gets access to the exported interface of M1.
As the basis for the discussion, we use Oberon-07 [57] as programming language but remove two language features that simplify the implementation
considerably.
First feature removed is nested procedures as it is difficult to find the accessible
state space of a nested procedure at compile time. Nested procedures do not add
additional functionality to the language but simply provide a nonessential structuring mechanism.
The second feature we remove is the export of read-only module variables.
Again, this helps the compiler to limit the state space and a procedure in a module
can access. Read-only variables can be simulated by wrapping them into exported
procedures.
Under these constraints, the only way of interaction between modules is by
accessing exported procedures. Generating a recovery point at cross-module
Fig. 8.5 Module imports
128
8 Recovery Preparation