293
3. Acquire the write lock to the bucket.
4. Insert the new node to the bucket by linking it to the list of nodes.
Because only one pointer has to be updated, a transaction is not
needed. Because only one pointer is updated, a transaction is not
required.
Erase Operation
Although the erase operation is similar to an insert (the opposite action), its
implementation is even simpler than the insert. The erase implementation
acquires the write lock for the required bucket and, using a transaction, removes the
corresponding node from the list of nodes within that bucket.
Summary
Although building an application for persistent memory is a challenging task, it is more
difficult when you need to create a multithreaded application for persistent memory.
You need to handle data consistency in a multithreaded environment when multiple
threads can update the same data in persistent memory.
If you develop concurrent applications, we encourage you to use existing libraries
that provide concurrent data structures designed to store data in persistent memory.
You should develop custom algorithms only if the generic ones do not fit your needs.
See the implementations of concurrent cmap and csmap engines in pmemkv, described
in Chapter 9, which are implemented using pmem::obj::concurrent_hash_map and
pmem::obj::concurrent_map, respectively.
If you need to develop a custom multithreaded algorithm, be aware of the limitation
PMDK transactions have for concurrent execution. This chapter shows that transactions
do not automatically provide isolation out of the box. Changes made inside one
transaction become visible to other concurrent transactions before they are committed.
You will need to implement additional synchronization if it is required by an algorithm.
We also explain that atomic operations cannot be used inside a transaction while
building lock-free algorithms without transactions. This is a very complicated task if your
platform does not support eADR.
Chapter 14 ConCurrenCy and persistent MeMory
3. Acquire the write lock to the bucket.
4. Insert the new node to the bucket by linking it to the list of nodes.
Because only one pointer has to be updated, a transaction is not
needed. Because only one pointer is updated, a transaction is not
required.
Erase Operation
Although the erase operation is similar to an insert (the opposite action), its
implementation is even simpler than the insert. The erase implementation
acquires the write lock for the required bucket and, using a transaction, removes the
corresponding node from the list of nodes within that bucket.
Summary
Although building an application for persistent memory is a challenging task, it is more
difficult when you need to create a multithreaded application for persistent memory.
You need to handle data consistency in a multithreaded environment when multiple
threads can update the same data in persistent memory.
If you develop concurrent applications, we encourage you to use existing libraries
that provide concurrent data structures designed to store data in persistent memory.
You should develop custom algorithms only if the generic ones do not fit your needs.
See the implementations of concurrent cmap and csmap engines in pmemkv, described
in Chapter 9, which are implemented using pmem::obj::concurrent_hash_map and
pmem::obj::concurrent_map, respectively.
If you need to develop a custom multithreaded algorithm, be aware of the limitation
PMDK transactions have for concurrent execution. This chapter shows that transactions
do not automatically provide isolation out of the box. Changes made inside one
transaction become visible to other concurrent transactions before they are committed.
You will need to implement additional synchronization if it is required by an algorithm.
We also explain that atomic operations cannot be used inside a transaction while
building lock-free algorithms without transactions. This is a very complicated task if your
platform does not support eADR.
Chapter 14 ConCurrenCy and persistent MeMory