FEAT: explicit barriers for intent API

[igchor]

FEAT: explicit barriers for intent API

Rationale

Some use cases require changes made by "publish" to guarantee some sort of ordering. For example, in multi threaded application user might want to store several values and a completion flag using intent API in one thread. Some other thread could check value of the flag and if set it could treat rest of values as initialized.

To make this work intent API would have to guarantee that the completion flag is stored after previous values are persisted (flush and drain). Additionally it should use some kind of thread fence. (something like atomic_thread_fence(memory_order_acquire))

Description

This could be implemented by exposing intents for emitting flush and drain and possibly intents for emitting a thread fence.

Flush_and_drain intents would also have to store information about how much of a redo log was already processed - on recovery we would have to continue from that point (not from the beginning).

Intents for thread fence would be runtime only (are not needed for recovery).

API Changes

Adding actions/intents for emitting a barrier.

Implementation details

[pbalcer]

https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf See epoch based reclamation, for suggested implementation of safe memory reclamation using pmemobj_defer_free().

[janekmi]

This improvement is not considered vital at the moment. So, we do not have the resources to fulfil your request. Sorry.