23
To insulate application developers from the complexities of the hardware and to keep
them from having to research and implement code specific to each platform or device,
the libpmem library provides a function that tells the application when optimized flush is
safe to use or fall back to the standard way of flushing stores to memory-mapped files.
To simplify programming, we encourage developers to use libraries, such as libpmem
and others within the PMDK. The libpmem library is also designed to detect the case of
the platform with a battery that automatically converts flush calls into simple SFENCE
instructions. Chapter 5 introduces and describes the core libraries within the PMDK in
more detail, and later chapters take an in-depth look into each of the libraries to help
you understand their APIs and features.
Data Visibility
When data is visible to other processes or threads, and when it is safe in the persistence
domain, is critical to understand when using persistent memory in applications. In the
Figure 2-2 and 2-3 examples, updates made to data in the CPU caches could become
visible to other processes or threads. Visibility and persistence are often not the same
thing, and changes made to persistent memory are often visible to other running threads
in the system before they are persistent. Visibility works the same way as it does for
normal DRAM, described by the memory model ordering and visibility rules for a given
platform (for example, see the Intel Software Development Manual for the visibility rules
for Intel platforms). Persistence of changes is achieved in one of three ways: either by
calling the standard storage API for persistence (msync on Linux or FlushFileBuffers
on Windows), by using optimized flush when supported, or by achieving visibility on
a platform where the CPU caches are considered persistent. This is one reason we use
flushing and fencing operations.
A pseudo C code example may look like this:
open() // Open a file on a file system
...
mmap() // Memory map the file
...
strcpy() // Execute a store operation
...
// Data is globally visible
msync() // Data is now persistent
Developing for persistent memory follows this decades-old model.
Chapter 2 persistent MeMory arChiteCture
To insulate application developers from the complexities of the hardware and to keep
them from having to research and implement code specific to each platform or device,
the libpmem library provides a function that tells the application when optimized flush is
safe to use or fall back to the standard way of flushing stores to memory-mapped files.
To simplify programming, we encourage developers to use libraries, such as libpmem
and others within the PMDK. The libpmem library is also designed to detect the case of
the platform with a battery that automatically converts flush calls into simple SFENCE
instructions. Chapter 5 introduces and describes the core libraries within the PMDK in
more detail, and later chapters take an in-depth look into each of the libraries to help
you understand their APIs and features.
Data Visibility
When data is visible to other processes or threads, and when it is safe in the persistence
domain, is critical to understand when using persistent memory in applications. In the
Figure 2-2 and 2-3 examples, updates made to data in the CPU caches could become
visible to other processes or threads. Visibility and persistence are often not the same
thing, and changes made to persistent memory are often visible to other running threads
in the system before they are persistent. Visibility works the same way as it does for
normal DRAM, described by the memory model ordering and visibility rules for a given
platform (for example, see the Intel Software Development Manual for the visibility rules
for Intel platforms). Persistence of changes is achieved in one of three ways: either by
calling the standard storage API for persistence (msync on Linux or FlushFileBuffers
on Windows), by using optimized flush when supported, or by achieving visibility on
a platform where the CPU caches are considered persistent. This is one reason we use
flushing and fencing operations.
A pseudo C code example may look like this:
open() // Open a file on a file system
...
mmap() // Memory map the file
...
strcpy() // Execute a store operation
...
// Data is globally visible
msync() // Data is now persistent
Developing for persistent memory follows this decades-old model.
Chapter 2 persistent MeMory arChiteCture