parent 22bdfea8
# Coupled-SFR
## Build instructions
Refer to build instructions in ./runtime/
## Persistent Region APIs
A preview is provided here. See `runtime/include/atlas_alloc.h` for the
actual interfaces.
A programmer needs to create one or more named persistent regions,
entities that hold everything persistent. The interface
**_NVM_FindOrCreateRegion_** or a variant can be used for this purpose. If a
region with the provided name exists, a handle to the region is
returned. Otherwise a region is created and its handle is
returned. Interfaces to close or delete a region are available.
To populate a persistent region, memory must be dynamically allocated
from that persistent region using **_nvm_alloc_** (or a variant) that has a
malloc-style interface. The region identifier must be provided so as
to identify the persistent region intended. An **_nvm_free_** is provided
for deallocation purposes.
Management of persistent regions and the contained data together
identify the persistent objects used by a program. Care must be taken
to ensure that all valid data within a persistent region is reachable
from the persistent root of the region. Use the interface
**_NVM_SetRegionRoot_** for this purpose.
## Consistency APIs
See `runtime/include/atlas_api.h` for the actual interfaces.
Persistent data must be kept consistent regardless of failures. The
programmer needs to call **_NVM_Initialize_** and **_NVM_Finalize_**
to start and stop Atlas support. Additionally, Atlas needs to know
code sections where program invariants are modified. If the program is
multithreaded and written using locks for synchronization, Atlas
automatically infers boundaries of regions where it must preserve
failure-atomicity (all-or-nothing) of updates to persistent
memory. Optionally, the programmer can demarcate sections of code with
calls to **_nvm_begin_durable_** and **_nvm_end_durable_** to identify
a durable or failure-atomic section of code. Note that no isolation
among threads is provided by a durable section. In contrast, if
persistent data is modified within a critical section, the critical
section provides both isolation among threads and durability to
persistent memory.
## Restart Code
A program might want to reuse data within a persistent region. For
this purpose, after finding a region handle, use the interface
**_NVM_GetRegionRoot_** to access the reachable data. Instead of
starting from scratch, this data can be reused to essentially restart
from where the region was left off the last time around.
That's all, as far as Atlas APIs are concerned. Compared to a
transient program, the idea is to write persistent memory programs
with as few changes as possible.
## Organization
- The APIs for this model are in `runtime/include`. [API doc here](
- Instructions on how to build the compiler-plugin are in
- Instructions on how to build the runtime are in `runtime/`.
- For example programs using Atlas, see `runtime/tests`.
- The Atlas library sources are in `runtime/src`.
## Dependencies
* Currently, we support only x86-64 CPUs
* We assume Linux OS. Linux tmpfs must be supported. Testing has been
done on RedHat and Ubuntu.
* We assume modern C/C++ compilers in the build environment that must
support C/C++11.
* The default compiler used in the build is clang. Testing has been
done with version 3.6.0 or later. The instrumentation support is
currently available only with clang/LLVM. The runtime should build
with any compiler supporting C/C++11 though clang is preferred for
uniformity purposes.
* cmake version 3.1 or later
* boost library
* bash 4.0
For Ubuntu 16.04, these dependencies can be installed with:
sudo apt-get install llvm clang cmake libboost-graph-dev
* ruby (for certain test scripts), see **Installing Ruby** at [gorails]( for instructions.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment