321
The benefit of this logging approach, in the context of persistent memory, is that all the
log entries can be written and flushed to storage at once. An optimal implementation of
redo logging uses only two synchronization barriers: once to mark the log as complete and
once to discard it. The downside to this approach is that the memory modifications are
not immediately visible, which makes for a more complicated programming model. Redo
logging can sometimes be used alongside load/store instrumentation techniques which
can redirect a memory operation to the logged location. However, this approach can be
difficult to implement efficiently and is not well suited for a general-purpose library.
Transaction Undo Logging
Undo logging is a method by which each memory region of a group (undo transaction)
that needs to be modified atomically is snapshotted into a log prior to the modification.
Once all memory modifications are complete, the log is discarded. If the transaction
is interrupted, the modifications in the log are rolled back to their original state.
Figure 16-5 shows the three phases of the transaction undo logging.
This type of log can have lower performance characteristics compared with the redo
log approach because it requires a barrier for every snapshot that needs to be made,
and the snapshotting itself must be fail-safe atomic, which presents its own challenges.
An undo log benefit is that the changes are visible immediately, allowing for a natural
programming model.
The important observation here is that redo and undo logging are complimentary.
Use redo logging for performance-critical code and where deferred modifications are
not a problem; use undo logging where ease of use is important. This observation led
to the current design of libpmemobj where a single transaction takes advantage of both
algorithms.
Figure 16-5. Phases of a transaction undo log
Chapter 16 pMDK Internals: IMportant algorIthMs anD Data struCtures
The benefit of this logging approach, in the context of persistent memory, is that all the
log entries can be written and flushed to storage at once. An optimal implementation of
redo logging uses only two synchronization barriers: once to mark the log as complete and
once to discard it. The downside to this approach is that the memory modifications are
not immediately visible, which makes for a more complicated programming model. Redo
logging can sometimes be used alongside load/store instrumentation techniques which
can redirect a memory operation to the logged location. However, this approach can be
difficult to implement efficiently and is not well suited for a general-purpose library.
Transaction Undo Logging
Undo logging is a method by which each memory region of a group (undo transaction)
that needs to be modified atomically is snapshotted into a log prior to the modification.
Once all memory modifications are complete, the log is discarded. If the transaction
is interrupted, the modifications in the log are rolled back to their original state.
Figure 16-5 shows the three phases of the transaction undo logging.
This type of log can have lower performance characteristics compared with the redo
log approach because it requires a barrier for every snapshot that needs to be made,
and the snapshotting itself must be fail-safe atomic, which presents its own challenges.
An undo log benefit is that the changes are visible immediately, allowing for a natural
programming model.
The important observation here is that redo and undo logging are complimentary.
Use redo logging for performance-critical code and where deferred modifications are
not a problem; use undo logging where ease of use is important. This observation led
to the current design of libpmemobj where a single transaction takes advantage of both
algorithms.
Figure 16-5. Phases of a transaction undo log
Chapter 16 pMDK Internals: IMportant algorIthMs anD Data struCtures