105
• The transactional API requires slow synchronization whenever
a variable is added to the transaction. If the variable is changed
multiple times during the transaction, subsequent operations are
free. It also allows conveniently mutating pieces of data larger than a
single machine word.
Guarantees of libpmemobj's APIs
The transactional, atomic allocation, and reserve/publish APIs within libpmemobj all
provide fail-safe atomicity and consistency.
The transactional API ensures the durability of any modifications of memory for
an object that has been added to the transaction. An exception is when the POBJ_X***_
NO_FLUSH flag is used, in which case the application is responsible for either flushing
that memory range itself or using the memcpy-like functions from libpmemobj. The
no-flush flag does not provide any isolation between threads, meaning partial writes are
immediately visible to other threads.
The atomic allocation API requires that applications flush the writes done by the
object’s constructor. This ensures durability if the operation succeeded. It is the only API
that provides full isolation between threads.
The reserve/publish API requires explicit flushes of writes to memory blocks
allocated via pmemobj_reserve() that will flush writes done via pmemobj_set_value().
There is no isolation between threads, although no modifications go live until pmemobj_
publish() starts, allowing you to take explicit locks for just the publishing stage.
Using terms known from databases, the isolation levels provided are
• Transactional API: READ_UNCOMMITTED
• Atomic allocations API: READ_COMMITTED
• Reserve/publish API: READ_COMMITTED until publishing starts, then
READ_UNCOMMITTED
Chapter 7 libpmemobj: a Native traNsaCtioNal objeCt store
• The transactional API requires slow synchronization whenever
a variable is added to the transaction. If the variable is changed
multiple times during the transaction, subsequent operations are
free. It also allows conveniently mutating pieces of data larger than a
single machine word.
Guarantees of libpmemobj's APIs
The transactional, atomic allocation, and reserve/publish APIs within libpmemobj all
provide fail-safe atomicity and consistency.
The transactional API ensures the durability of any modifications of memory for
an object that has been added to the transaction. An exception is when the POBJ_X***_
NO_FLUSH flag is used, in which case the application is responsible for either flushing
that memory range itself or using the memcpy-like functions from libpmemobj. The
no-flush flag does not provide any isolation between threads, meaning partial writes are
immediately visible to other threads.
The atomic allocation API requires that applications flush the writes done by the
object’s constructor. This ensures durability if the operation succeeded. It is the only API
that provides full isolation between threads.
The reserve/publish API requires explicit flushes of writes to memory blocks
allocated via pmemobj_reserve() that will flush writes done via pmemobj_set_value().
There is no isolation between threads, although no modifications go live until pmemobj_
publish() starts, allowing you to take explicit locks for just the publishing stage.
Using terms known from databases, the isolation levels provided are
• Transactional API: READ_UNCOMMITTED
• Atomic allocations API: READ_COMMITTED
• Reserve/publish API: READ_COMMITTED until publishing starts, then
READ_UNCOMMITTED
Chapter 7 libpmemobj: a Native traNsaCtioNal objeCt store