0%

Motivatione

a previous single-layer NVM database N2DB[14] used the snapshot isolation from PostgreSQL[17]. Its snapshot generation process involves taking a lock and scanning a global active transaction list, which blocks concurrent transactions and is not scalable

Background

2.3 Concurrency control for NVM databases

The snapshot isolation concurrency control implementation used in traditional MVCC databases is not well suited for NVM because of two reasons. (1) The concurrency control implementations of traditional databases mainly focus on their in-memory part without discussing durability and crash consistency. They leave those to another dedicated recovery protocol, such as ARIES or write-ahead logging. The situation is different in NVM databases because a single copy of data is used for both runtime access and durability. Ensuring crash consistency should unavoidably be part of the concurrency control itself. (2) Concurrency control methods from a two-layer architecture have suboptimal performance when directly applied to a single-layer NVM database. FOEDUS[28] points out that centralized components, such as lock manager and logs in traditional concurrency control implementations, will cause performance bottlenecks in a multicore NVM database. A previous NVM database N2DB[14] adopted the concurrency control from PostgreSQL[17] to implement snapshot isolation. The concurrency control scheme from PostgreSQL uses the currently completed transactions in the system to represent a snapshot. When generating a snapshot, it has to take a lock and scan the global active transaction list. This approach blocks concurrent transactions and is not scalable. N2DB also adopted the commit log in NVM to persistently store transaction status for crash consistency. The commit log is an array-like structure and is write-shared by all threads, which limits its scalability. Zen[29] also points out that traditional concurrency control methods often need to modify the tuple metadata not only by tuple writes but also by tuple reads, which incurs expensive NVM writes.

Multi-Clock Concurrency Control

转载自csdn

简介

getopt函数是命令行参数解析函数,在头文件getopt.h中,这里对齐用法做一个简单的介绍。

阅读全文 »

glog

glog是谷歌开源的C++日志库,这里对glog进行一个简单的学习记录。

阅读全文 »

安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 用这个版本
wget https://github.com/apple/foundationdb/releases/download/7.2.3/foundationdb-server_7.2.3-1_amd64.deb
wget https://github.com/apple/foundationdb/releases/download/7.2.3/foundationdb-clients_7.2.3-1_amd64.deb
# 安装
sudo dpkg -i foundationdb-clients_7.2.3-1_amd64.deb
sudo dpkg -i foundationdb-server_7.2.3-1_amd64.deb
# 卸载
sudo dpkg --purge foundationdb-server
sudo dpkg --purge foundationdb-clients


wget https://github.com/apple/foundationdb/releases/download/6.2.11/foundationdb-server_6.2.11-1_amd64.deb
wget https://github.com/apple/foundationdb/releases/download/6.2.11/foundationdb-clients_6.2.11-1_amd64.deb
sudo dpkg -i foundationdb-clients_6.2.11-1_amd64.deb
sudo dpkg -i foundationdb-server_6.2.11-1_amd64.deb
sudo dpkg --purge foundationdb-server
sudo dpkg --purge foundationdb-clients

阅读全文 »

参考:https://blog.csdn.net/lizhichao410/article/details/123732787

使用背景

在C++中使用std::thread可创建一个线程,使用互斥量std::mutex来确保多个线程对共享数据的读写操作同步问题;使用std::condition_variable来解决线程执行顺序的同步问题。那么多个线程之间怎么传递数据呢?其中一种做法是使用一个全局变量,然后让线程之间互斥的访问就可以传递数据,还有一种做法就是使用std::future和std::async。

阅读全文 »

本篇文章主要验证普通函数和内联函数的区别

Inline_function.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
__attribute__((always_inline))
inline void func() {
int j = 0;
for (int i = 0; i < 2; i++) {
j++;
if (j == 20) j *= 2;
}
}

int main() {
func();
func();
func();
func();
func();
return 0;
}

__attribute__((always_inline))告诉编译器强制内联。

阅读全文 »

转载自https://baijiahao.baidu.com/s?id=1710441201075985657&wfr=spider&for=pc

什么是跳表?

类似MineCraft的地狱交通,在地狱走一个相当于主世界走8格

跳表全称为跳跃列表,它允许快速查询,插入和删除一个有序连续元素的数据链表。跳跃列表的平均查找和插入时间复杂度都是O(logn)。快速查询是通过维护一个多层次的链表,且每一层链表中的元素是前一层链表元素的子集(见右边的示意图)。一开始时,算法在最稀疏的层次进行搜索,直至需要查找的元素在该层两个相邻的元素中间。这时,算法将跳转到下一个层次,重复刚才的搜索,直到找到需要查找的元素为止。

img

一张跳跃列表的示意图。每个带有箭头的框表示一个指针, 而每行是一个稀疏子序列的链表;底部的编号框(黄色)表示有序的数据序列。查找从顶部最稀疏的子序列向下进行, 直至需要查找的元素在该层两个相邻的元素中间。

阅读全文 »

memory consistency model

image-20220903234055396

由于一些优化(可能来自编译器或者操作系统或者硬件之类的),在核1真正执行的时候可能不会按照程序原有的顺序执行,比如core1会将两个操作交换顺序,这就导致多个核之间的执行顺序可能会任意进行。为了让结果符合预期,就产生了memory consistency model这一概念,以及各种不同的memory model。

阅读全文 »