持久性内存编程——事务

最新推荐文章于 2024-08-30 09:40:17 发布

SweeNeil

最新推荐文章于 2024-08-30 09:40:17 发布

阅读量887

点赞数

分类专栏：存储 Linux 持久化(性)内存/非易失性内存文章标签：持久性内存事务

Linux 同时被 3 个专栏收录

38 篇文章 4 订阅

订阅专栏

存储

26 篇文章 5 订阅

订阅专栏

持久化(性)内存/非易失性内存

14 篇文章 9 订阅

订阅专栏

在之前一直用的持久化内存，现在感觉有一种说不出的怪怪的感觉，之后都改为持久性内存。

前面介绍了访问持久性内存的方式，其中抛出了一些在持久性内存上编程的要点，接下来就翻译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中列出的一系列阶段，其过程如下图所示：

lifecycle

可以使用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_END

	free(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_END

	return ret;
}