219
Running the modified code through pmemcheck reports no issues, as shown in
Listing 12-12.
Listing 12-12. Running pmemcheck with code Listing 12-11
$ valgrind --tool=pmemcheck ./listing_12-11
==9710== pmemcheck-1.0, a simple persistent store checker
...
==9710== Number of stores not made persistent: 0
==9710== ERROR SUMMARY: 0 errors
Because Intel Inspector – Persistence Inspector does not consider an unflushed write a
problem unless there is a write dependency with other variables, we need to show a more
complex example than writing a single variable in Listing 12-7. You need to understand
how programs writing to persistent memory are designed to know which parts of the data
written to the persistent media are valid and which parts are not. Remember that recent
writes may still be sitting on the CPU caches if they are not explicitly flushed.
Transactions solve the problem of half-written data by using logs to either roll back
or apply uncommitted changes; thus, programs reading the data back can be assured
that everything written is valid. In the absence of transactions, it is impossible to know
whether or not the data written on persistent memory is valid, especially if the program
crashes.
A writer can inform a reader that data is properly written in one of two ways, either
by setting a “valid” flag or by using a watermark variable with the address (or the index,
in the case of an array) of the last valid written memory position.
Listing 12-13 shows pseudocode for how the “valid” flag approach could be
implemented.
Listing 12-13. Pseudocode showcasing write dependency of var1 with var1_valid
1 writer() {
2
var1 = "This is a persistent Hello World
3
written to persistent memory!";
4
flush (var1);
5
var1_valid = True;
6
flush (var1_valid);
7 }
8
Chapter 12 Debugging persistent MeMory appliCations
Running the modified code through pmemcheck reports no issues, as shown in
Listing 12-12.
Listing 12-12. Running pmemcheck with code Listing 12-11
$ valgrind --tool=pmemcheck ./listing_12-11
==9710== pmemcheck-1.0, a simple persistent store checker
...
==9710== Number of stores not made persistent: 0
==9710== ERROR SUMMARY: 0 errors
Because Intel Inspector – Persistence Inspector does not consider an unflushed write a
problem unless there is a write dependency with other variables, we need to show a more
complex example than writing a single variable in Listing 12-7. You need to understand
how programs writing to persistent memory are designed to know which parts of the data
written to the persistent media are valid and which parts are not. Remember that recent
writes may still be sitting on the CPU caches if they are not explicitly flushed.
Transactions solve the problem of half-written data by using logs to either roll back
or apply uncommitted changes; thus, programs reading the data back can be assured
that everything written is valid. In the absence of transactions, it is impossible to know
whether or not the data written on persistent memory is valid, especially if the program
crashes.
A writer can inform a reader that data is properly written in one of two ways, either
by setting a “valid” flag or by using a watermark variable with the address (or the index,
in the case of an array) of the last valid written memory position.
Listing 12-13 shows pseudocode for how the “valid” flag approach could be
implemented.
Listing 12-13. Pseudocode showcasing write dependency of var1 with var1_valid
1 writer() {
2
var1 = "This is a persistent Hello World
3
written to persistent memory!";
4
flush (var1);
5
var1_valid = True;
6
flush (var1_valid);
7 }
8
Chapter 12 Debugging persistent MeMory appliCations