本文主要是介绍持久性内存编程——事务,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
在之前一直用的持久化内存,现在感觉有一种说不出的怪怪的感觉,之后都改为持久性内存。
前面介绍了访问持久性内存的方式,其中抛出了一些在持久性内存上编程的要点,接下来就翻译pmem.io上的第二个编程指导——事务。
原文来自:http://pmem.io/2015/06/15/transactions.html
目录
生命周期
事务操作
条件事务块
示例
通过前一部分的介绍(https://blog.csdn.net/SweeNeil/article/details/90296581),现在应该对持久性内存编程的基础知识非常熟悉了。
了确保应用程序的一致性,通过之前学习的知识,我们还必须依赖自己的解决方案和技巧 - 例如前一个示例中的缓冲区长度。
本文将介绍pmemobj库为这类问题提供的通用解决方案 - 事务。
目前我们仅关注没有加锁的单线程应用程序。
生命周期
在pmemobj库中,通过使用pmemobj_tx_ *系列函数来管理事务。
单个事务将经历enum pobj_tx_stage中列出的一系列阶段,其过程如下图所示:
可以使用pmemobj_tx_process函数代替其他函数来移动事务 - 如果不知道当前处于哪个阶段,可以调用它。
为了避免对整个过程进行微观管理,pmemobj库提供了一组构建在这些函数之上的宏,这些宏极大地简化了事务的使用,本教程将专门使用它们。
下面就是整个事务块的样子:
/* TX_STAGE_NONE */TX_BEGIN(pop) {/* TX_STAGE_WORK */
} TX_ONCOMMIT {/* TX_STAGE_ONCOMMIT */
} TX_ONABORT {/* TX_STAGE_ONABORT */
} TX_FINALLY {/* TX_STAGE_FINALLY */
} TX_END/* TX_STAGE_NONE */
从上面我们可以看出,这与生命周期图非常密切相关。
除TX_BEGIN和TX_END之外的所有代码块都是可选的。
可以没有任何限制地嵌套事务,递归事务在技术上也是可以的。
如果嵌套事务中止,则整个事务将中止。
开发者可能想知道为什么存在TX_FINALLY阶段,为什么不在事务块之后执行该代码 - 好吧,由于事务工的作方式(在开始时setjmp和所有中止的longjmp),不能保证代码是在嵌套事务中的TX_END之后直接执行。
例如如下代码:
void do_work() {struct my_task *task = malloc(sizeof *task);if (task == NULL) return;TX_BEGIN(pop) {/* important work */pmemobj_tx_abort(-1);} TX_ENDfree(task);
}...
TX_BEGIN(pop)do_work();
TX_END
此代码段有内存泄漏,它永远不会调用free,因为do_work中的TX_END最终会使longjmp返回到外部事务 实现do_work的正确方法是使用TX_FINALLY:
void do_work() {volatile struct my_task *task = NULL;TX_BEGIN(pop) {task = malloc(sizeof *task);if (task == NULL) pmemobj_tx_abort(ENOMEM);/* important work */pmemobj_tx_abort(-1);} TX_FINALLY {free(task);} TX_END
}
上述代码保证了finally块总是会被执行。
另请注意TX_FINALLY块中volatile限定变量的用法。 这是因为本地非易失性限定对象如果它们的值在setjmp之后已更改,在执行longjmp后具有未定义的值。
因此,对于libpmemobj事务块,在TX_STAGE_WORK中修改并在TX_STAGE_ONABORT / TX_STAGE_FINALLY中使用的每个局部变量都需要进行volatile限定 - 否则可能会遇到未定义的行为。
有关更多信息,可以参考libpmemobj manpage 中的CAVEATS部分。
事务操作
pmemobj库区分了3种不同的事务操作:分配(allocation),释放(free)和设置(set)。
在本文中只介绍最后一个,顾名思义,它用于安全地将内存块设置为某个值。 这是通过2个API函数实现的:
- pmemobj_tx_add_range
- pmemobj_tx_add_range_direct
引用文档:
获取内存块的“快照”...并将其保存在撤消日志中,应用程序可以直接修改该内存范围内的对象,如果发生故障或中止,此范围内的所有更改都将自动回滚。
这意味着当调用上述两个函数中的任何一个时,将分配一个新对象并将内存范围的现有内容复制到其中。
除非库在事务回滚中需要旧内存,否则该对象将被丢弃。另请注意,该库假定当添加要写入的内存范围时,并且在提交事务时内存会自动保留 - 因此不必自己调用pmemobj_persist。
那么如何使用这些功能呢? pmemobj_tx_add_range采用原始持久性内存指针(PMEMoid),它与它的偏移量及其大小。 所以可以在这个结构中设置一些值:
struct vector {int x;int y;int z;
}PMEMoid root = pmemobj_root(pop, sizeof (struct vector));
简单的使用方式如下:
struct vector *vectorp = pmemobj_direct(root);
TX_BEGIN(pop) {pmemobj_tx_add_range(root, offsetof(struct vector, x), sizeof(int));vectorp->x = 5;pmemobj_tx_add_range(root, offsetof(struct vector, y), sizeof(int));vectorp->y = 10;pmemobj_tx_add_range(root, offsetof(struct vector, z), sizeof(int));vectorp->z = 15;
} TX_END
但这不是最优的 - 使用该方法在撤消日志中添加三个对象。
其实单个撤消日志条目的大小至少等于128字节就足够了,最好一次添加整个对象:
struct vector *vectorp = pmemobj_direct(root);
TX_BEGIN(pop) {pmemobj_tx_add_range(root, 0, sizeof (struct vector));vectorp->x = 5;vectorp->y = 10;vectorp->z = 15;
} TX_END
这样就不会为元数据浪费不必要的内存,效果将完全相同。
pmemobj_tx_add_range_direct执行相同的操作,但是以更方便的方式用于某些用途,它直接引用字段及其大小,例如:
struct vector *vectorp = pmemobj_direct(root);
int *to_modify = &vectorp->x;
TX_BEGIN(pop) {pmemobj_tx_add_range_direct(to_modify, sizeof (int));*to_modify = 5;
} TX_END
当没有简单的方法来访问此内存块所属的PMEMoid时,这非常有用。
条件事务块
It might seem that and explanation isn’t really required, one is called when the transaction commits and the other one when it aborts - simple as that. As long as there are no inner transactions, that is true. But once we start nesting, things get a little bit more complicated. Consider the following example:
TX_ONCOMMIT
和TX_ONABORT,
一个在事务提交时调用,另一个在事务被中止时调用。只要没有内部事务,这就很简单,但一旦我们开始事务层叠,事情就变得有点复杂了。考
虑以下代码:
#define MAX_HASHMAP 1000
TOID(struct hash_entry) hashmap[MAX_HASHMAP]; /* volatile hashmap */void hash_set(int key, int value) {TOID(struct hash_entry) nentry;TX_BEGIN(pop) {nentry = TX_NEW(struct hash_entry);D_RW(nentry)->key = key;D_RW(nentry)->value = value;} TX_ONCOMMIT {size_t hash = hash_func(key);if (TOID_IS_NULL(hashmap[hash]))hashmap[hash] = nentry;else/* ... */} TX_END
}TX_BEGIN(pop) {hash_set(5, 10);pmemobj_tx_abort(-1);
} TX_END
上述代码中,一个哈希映射,其中包含持久内存中的条目,但包含它们的易失性hash表。
此代码正确吗?
散列值自己设置是完全正常的-但不在另一个事务中。当调用pmemobj_tx_abort函数时,将还原tx_begin块中的所有内容,但嵌套事务的tx_oncommit已执行(并且不会在该函数中调用tx_onabort),最终结果是volatile表中的无效持久指针。
这通常很难解决,需要每个问题的解决方案-我建议设计应用程序以主动避免它。对于这个特定的用例,您可以有一个额外的hash-revert-previous函数,该函数是从最外层事务的tx-onabort块调用的。
tx-oncommit和tx-onabort的预期用途是打印日志信息,并使用嵌套事务设置函数的返回变量,如下所示:
int do_work() {int ret;TX_BEGIN(pop) {} TX_ONABORT {LOG_ERR("work transaction failed");ret = 1;} TX_ONCOMMIT {LOG("work transaction successful");ret = 0;} TX_ENDreturn ret;
}
示例
here
这篇关于持久性内存编程——事务的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!