picotm
0.9.0
|
Picotm is extensible. This section explains the module interface and how to implement your own module on top. More...
Files | |
file | compiler.h |
Contains macros for dealing with compiler extensions. | |
file | picotm-error.h |
Contains struct picotm_error and helper functions. | |
file | picotm-lib-array.h |
file | picotm-lib-ptr.h |
file | picotm-lib-ref.h |
file | picotm-lib-rwlock.h |
file | picotm-lib-rwstate.h |
Contains struct picotm_rwstate and helpers. | |
file | picotm-lib-shared-ref-obj.h |
Contains struct picotm_shared_ref16_obj and helper functions. | |
file | picotm-lib-shared-treemap.h |
Contains struct picotm_shared_treemap and helper functions. | |
file | picotm-lib-spinlock.h |
Contains struct picotm_spinlock and helper functions. | |
file | picotm-lib-tab.h |
file | picotm-lib-treemap.h |
Contains struct picotm_treemap and helpers. | |
file | picotm-module.h |
Picotm's module interface. | |
Picotm is only a transaction manager. It maintains transactions but doesn't provide their functionality. All actual transactional operations are provided by additional modules. Picotm can be extended with arbitrary functionality. The interface is available to external libraries, so no modification to picotm is required.
To register a module, call picotm_register_module(). The call receives a number of module-specific call-back functions and module data, and returns a unique module number. The call-back functions are invoked by picotm to instruct the module during different phases of a transaction. The returned module number is later required when inserting events into the transaction log.
For an example, let's look at a transactional allocator. Registering the module might look like this.
Modules are registered per-thread. You have to register your module on each thread where it is used.
When the user invokes an operation of your module, the module might wants to store an event in the transaction log. This is done by invoking picotm_inject_event(). During the transaction's commit, events in the transaction log are applied in the order they appear in the log. During a roll-back, events are reverted in opposite order.
In the case of our transactional allocator, we have two functions, malloc()
and free()
.
For applying or reverting events, your module must provide the respective callbacks to picotm_register_module(). These are invoked by picotm during the life time of a transaction.
For our example of the transactional allocator, these call-back functions will look like this.
In our example we have registered a module for a transactional allocator. The malloc operation allocates memory, but reverts this allocation during an undo. The free operation doesn't actually free the memory immediately, but creates an event to free the memory during a commit.