普通视图

使用原子 TAS 指令实现自旋锁

使用原子 TAS 指令实现自旋锁

使用原子 TAS 指令实现自旋锁 Implementing a Spinlock Using the Atomic TAS Instruction 从零实现自旋锁:基于 TAS 的最小同步原语 Building a Spinlock from Scratch with Atomic TAS 用 test-and-set 实现最简单的互斥锁 Implementing a Minimal Mutex Using Test-and-Set 自旋锁的底层原理:TAS、原子性与忙等待 Inside Spinlocks: TAS, Atomicity, and Busy Waiting 原子操作与自旋锁:用 C 语言实现线程同步 Atomic Operations and Spinlocks: Thread Synchronization in C 从原子指令到锁:全面理解 TAS 和自旋锁 From Atomic Instructions to Locks: A Complete Guide to TAS and Spinlocks 动手写一个自旋锁:tryLock / lockAcquire / lockRelease 全实现 Hands-On Spinlock Implementation: tryLock, lockAcquire, and lockRelease 你的第一个自旋锁:基于 C 语言的 TAS 实现 Your First Spinlock: A TAS-Based Implementation in C 原子交换与线程互斥:自旋锁实现指南 Atomic Exchange and Thread Mutual Exclusion: A Guide to Implementing Spinlocks
假设我们有一个 TAS(Take-And-Set)函数。该操作返回内存中原来的值,并以原子方式将其替换为新值。原子性(atomicity)意味着没有其他线程能够观察到中间状态;整个读-写操作是一体不可分的。 在 C++ 中,标准库函数 std::exchange 在逻辑上表现相同,但它不是原子操作。同步原语需要硬件级别的原子性。
int TAS(int* memory, int newVal) {
    int old = *memory;
    *memory = newVal;
    return old;
}
我们想使用这个原语来实现一个简单的自旋锁,包括:
  • lockAcquire()
  • lockRelease()
线程将调用这些函数来保护对共享变量的访问:
typedef struct {
    int lock;
} lockType;

typedef struct {
    int val;
} threadArgType;

void threadFunc(void* arg) {
    lockAcquire((static_cast<lockType*>arg)->lock);
    (static_cast<threadArgType*>arg)->val++;
    lockRelease((static_cast<lockType*>arg)->lock);
}

实现 tryLock

tryLock 函数尝试获取锁一次。如果锁为空(值为 0),TAS 将其设置为 1 并返回原值(0)。如果锁已被占用,TAS 返回 1。tryLock 函数是非阻塞的——它会立即返回。 因此 tryLock() 只有在 TAS 返回 0 时才会成功:
enum {
    UNLOCKED = 0,
    LOCKED = 1
}

int tryLock(lockType* lock) {
    // 如果之前已锁定返回 1,如果之前未锁定返回 0
    int old = TAS(lock->lock, LOCKED);
    return (old == UNLOCKED);   // true (1) = 成功获取锁
}

实现 lockAcquire()

普通的锁获取应当“自旋”直到 tryLock() 成功。这称为 自旋锁,因为 CPU 会忙等待。必要时可以加入短暂的 sleep。例如,sleep(0) 并不会真正暂停执行,而是让出 CPU,允许其他线程运行。 它通常用于实现跨线程的互斥自旋锁。
void lockAcquire(lockType* lock) {
    while (!tryLock(lockType* lock)) {
        // 自旋直到锁可用
    }
}
另一种实现:
void lockAcquire(lockType* lock) {
    do {
       if (tryLock(lockType* lock)) {
          break;
       }
    } while (1);
}
展开 tryLock:
void lockAcquire(lockType* lock) {
    do {
       int old = TAS(lock->lock, LOCKED);
       // 无论锁是否已被获取,锁都已设置为 LOCKED
       if (old == UNLOCKED) {
           break;
       }
    } while (1);
}
这是使用 TAS 实现的最简单方法。在实际系统中,我们可能会加入 pause 指令或退避策略,但基本思路是相同的。

实现 lockRelease()

释放锁时,持有者只需将锁变量写为 0。由于 TAS 是“设置新值并返回旧值”,它同样适用于释放锁:
void lockRelease(lockType* lock) {
    TAS(lock->lock, UNLOCKED);
}
或者使用简单的原子存储也足够,但由于 TAS 是我们唯一的工具,我们重用它。请注意,在这里重复释放锁是安全的,因为再次将其设置为 UNLOCKED=0 不会产生副作用。

总结

仅使用原子 TAS 指令,我们实现了:
  • 一个 tryLock() 尝试
  • 一个 lockAcquire() 自旋锁
  • 一个 lockRelease() 解锁操作
这种锁的实现方式对于理解低级并发、内存顺序以及高层互斥锁库的构建方式非常基础。 [show_file file="/var/www/wp-post-common/justyy.com/cpp.php"] 英文:Implement a Lock Acquire and Release in C++

相关文章:

  1. 简易教程: C++的智能指针 C++ 智能指针教程 C++ 中的智能指针提供了自动且安全的内存管理。它们通过 RAII(资源获取即初始化)机制,帮助开发者避免内存泄漏和悬空指针的问题,确保对象在生命周期结束时被正确释放。 本教程将介绍 C++ 中三种主要的智能指针: std::unique_ptr:独占式所有权 std::shared_ptr:共享式所有权 std::weak_ptr:非拥有式弱引用 1. std::unique_ptr unique_ptr 拥有独占所有权。一个资源只能被一个...
  2. C++中的 const和constexpr 比较 C++ const 与 constexpr:真正的区别是什么? 一眼看都是定义常量。 为什么这很重要 现代 C++ 鼓励编写不可变、高效且表达力强的代码。两个关键字—const 和 constexpr—是这一理念的核心。它们看起来很相似,但理解它们的不同语义,对于正确利用编译期与运行期行为至关重要。 高层次对比 特性 const constexpr...
  3. 被动收入之: 微博红包 今年开始重新经营我的微博帐号 drlai 收到两笔微信红包,应该是来自于官方的支持,150元(成功提现到支付宝)。虽然这不能持久,也没多少,但毕竟实现了零的突破,意义重大。 如果流量上来,内容创作者可能会接受到比较多的赞赏,这也是一个比较简单的变现方法。这也能作为一种被动收入,不过如果不是头部网红,可能杯水车薪,但如果你有好几个类似这样的,也能积少成多! 在用户中心,微博用户可以每天登陆手机微博APP打卡,获取点数和少量的红包钱(几分钱),积少成多! 微博做些小任务可获得积分和几分钱。聊胜于无。 微博的主要盈利模式 微博的主要盈利模式主要包括以下几个方面: 广告收入:微博的大部分收入来源于广告,尤其是品牌广告和效果广告。广告形式包括信息流广告(类似于推文广告)、热门话题广告、开屏广告和视频广告。品牌和企业可以利用微博庞大的用户群和社交互动来提升曝光率、推广品牌和产品。 会员服务:微博提供的VIP会员服务,用户可以支付订阅费用来享受更多的特权,比如个性化的主题、特有的表情包、私密权限设置等。这些会员服务主要面向个人用户,提升其社交体验。 直播和打赏:微博提供直播平台,用户可以通过购买虚拟礼物来支持主播,微博会从这些打赏中抽取一定比例的分成。此外,微博与内容创作者分成,通过内容付费、知识付费等形式变现。 增值服务:针对企业和大V(拥有大量粉丝的用户),微博还提供增值服务,如账号认证、粉丝数据分析、精准推送、推广和营销工具等。这些服务帮助企业提升营销效果,同时也增加了微博的收入来源。 电商和导流:微博上有大量的电商导流业务,尤其是和明星、网红的合作推广。微博用户在浏览社交内容时,可以直接跳转到商品购买链接,微博通过这种方式赚取导流佣金。 游戏联运:微博也会与一些游戏公司合作推出联合运营的游戏,微博负责推广和流量引入,用户充值或付费时,微博可以获得一部分的分成。 这些模式相结合,使得微博能够在广告市场、内容创作和电商等多个领域获利。...
  4. 借助AI快速开源了N个小工具: 写代码越来越像做产品了, AI 真把我宠坏了(Vibe Coding) 程序员的未来?Vibe Coding + AI 一起上! 借助 AI 快速开源了三个小工具 最近,我利用 ChatGPT-4o 和 o4-mini 快速开发并开源了几个小工具。起因其实很简单——每次想转换 YAML/JSON 或进行...
  5. 豪车的修理费用就是贵一些 去年买了保时捷卡宴SUV(Porsche Cayenne)后,我一直担心将来修车费用会很高。当时购车时,车厂做了一次全面保养,把车里里外外都清洁了一遍。虽然这辆车已经三年车龄,但看上去几乎和新车没区别。 在英国,三年以内的新车通常不需要做MOT年检。而且很多这类新车会通过PCP(个人合同购车)方式出租给车主。简单来说,就是车主每月支付一笔租金,租期通常为三年,期满后可以选择一次性付清尾款买下车辆,也可以继续换租一辆新车。 举个例子,如果一辆新车售价是10万英镑,车厂可能按未来三年折旧后的50%残值来计算每月租金。三年后,如果车主不想买断,车厂就会将车辆作为二手车卖出,回收那5万英镑的残值。这样一来,车厂基本不会亏钱。此外,PCP合同中还有附加条款,比如每年限行1万英里,超出的部分需要额外付费,这些内容都会写在合同里。 车龄到了三年,车辆需要首次做MOT年检,同时车辆的市场价值也会首次出现较大幅度的贬值(一般是50%,甚至更多)。修车厂老板告诉我,相比玛莎拉蒂等其他豪车,保时捷的保值率相对较高。 这一年我开这辆保时捷基本没出什么问题。今年年初做了年检,顺利通过。随后又做了一次常规保养,修车厂老板告诉我,前后刹车片已经磨损了80%–85%。我们住剑桥村里,开车比较多(上班、送娃、家庭旅游都要用车),一年大概能开1-2万英理。 几周后我将车送回去更换刹车片。修完后账单是将近900英镑。我觉得有点贵,车行老板解释说,不仅换了前后刹车片,还有一个前雷达的传感器掉进了车体内部,为了修这个传感器需要拆掉前保险杠等部件,花了6个小时人工费。 我当时质疑说为啥这次修这么贵,他说:“因为这是保时捷。”我说:“那和别的车有什么区别?”他说:“It is not the same.” 我说不都一样么,他说:“It is not...
  6. 重要通知: 弃用 FeedBurner RSS 请改用 https://justyy.com/feed 最近我发现原本的 RSS(/rss、/feed)没有按时更新。 进一步检查后发现这些地址都被 301 重定向到了 FeedBurner(https://feeds.feedburner.com/zhihua-xblog),而 FeedBurner 已经久未维护,偶有抓取失败或延迟,导致读者无法及时收到新文章。 造成这次重定向的原因是我们使用的第三方主题/插件(mytheme)里曾经内置了将站点 feed 转发到 FeedBurner 的功能。 当时之所以做 301...
  7. 换了个奥迪Q5大灯花了我1000英镑 我那辆奥迪Q5 SUV今年年检没通过,原因是左前车灯坏了,需要更换。车厂告诉我,光是订购零件就要700多英镑,加上人工费,总费用得1000英镑。但没办法,如果不修,车辆年检(MOT)就过不了,车也不能上路。 MOT是英国的机动车强制性安全检测(Ministry of Transport Test)的简称。 近侧前位置灯不工作 drl/位置灯集成(4.2.1(a)(ii)) Nearside Front Position lamp not working drl/position...
  8. 你给SteemIt中文微信群拖后腿了么? 这年头不缺算法, 就缺数据. 这两天花了很多时间在整API上, 整完之后自己用了一下还觉得真是挺方便的. 今天就突然想看一看自己是否给大家拖后腿了, 于是调用每日中文区微信群排行榜单的API, 刷刷拿着 NodeJs 练手: // @justyy var request = require("request")...

谈谈分布式锁

2024年9月19日 07:33

不要使用分布式锁

就像 Martin Fowler 说的那样,“分布式调用的第一原则就是不要分布式”,谈分布式锁也要先说,不要使用分布式锁。原因很简单,分布式系统是软件系统中复杂的一种形式,而分布式锁是分布式系统中复杂的一种形式,没有必要的复杂性就不要引入。

有的逻辑是没有副作用的(纯函数代码),那就可以无锁执行;有的数据经过合理的 sharding 之后,可以使用单线程(单节点)执行,那就单线程执行。

比如一种常见的模式就是使用 queue(比如 Kafka),任务全部放到队列中,然后根据 sharding 的逻辑,不同的 consumer 来处理不同的任务,互相之间不会干扰冲突。

还有一个例子是 Kotlin Coroutine,通过指定一个单线程的 dispatcher,也可以保证它执行的操作之间互相不会有多线程的冲突问题。

有了这样的原则以后,再来谈谈几种分布式锁。

数据库锁

分布式系统中,我觉得我们最常见的锁就是使用一个中心数据库来做的。

一种是悲观锁,就是 “select xxx … for update” 这样的,相应的数据行会被锁上,直到 commit/rollback 操作发生。如果被别人锁了,当前线程没得到锁的话就会等着。

还有一种是乐观锁,就是使用版本号,“update … where … version=A” 这样的。如果 update 成功,表示获取锁成功,并且操作也成功;否则就是 update 失败,需要重新获取状态再来操作一遍。

大多数情况下,后者要更高效一些,因为阻塞的时间通常更短,不过在锁竞争比较激烈的情况下,反而效率会反过来。另外一个,悲观锁代码写起来会容易一些,因为 select 语句执行和 commit/rollback 是两步操作,因此二者之间可以放置任意逻辑;而乐观锁则是需要把数据的写操作和 version 的比较放在一条语句里面。

这两种都很常见,基本上我接触过的一半以上的项目都用过两者。这个数据库不一定非得是关系数据库,但是强一致性必须是保证的。

S3

使用 S3 来创建文件,让创建成功的节点得到锁,文件里面也可以放自定义的内容。我们去年的项目用到这个机制。这种方式是建立在 S3 2020 年 12 月 1 日,上线的 strong consistency 的 feature

大致上,有这样两种思路:

  1. 使用 S3 versioning,就是说,在 versioning 打开的情况下,文件的写入不会有 “覆盖” 的情况发生,所有内容都会保留。在创建文件的时候,response 种会有一个 x-amz-version-id header。节点写入文件后,再 list 一下所有的 version,默认这些 version 会根据创建的时间顺序递减排列,后创建的在前,因此比较其中最早的那个 version 和自己创建文件后得到的 version,如果两者相等,说明自己得到了锁。
  2. 使用 S3 Object Lock,这个可以控制让第一次写成功,后面的操作全部失败,所以第一次写入成功的节点得到锁。

使用这种方式,对于那些本来就需要使用 S3 文件系统来共享任意信息的情况很方便,但是需要自己处理超时的问题,还有 retention 策略(该不该/什么时候删掉文件)。

Redlock

Redlock 就是 Redis 的锁机制。Martin Kleppmann(就是那个写《Design Data-Intensive Applications》的作者)几年前写过一篇文章,来吐槽 Redlock 在几种情况下是有问题的:

  1. Clock jump:Redlock 依赖于物理时钟,而物理时钟有可能会跳(jump),并且这种状况是无法预测的。Clock jump 就是说,始终会不断进行同步,而同步回来的时间,是有可能不等于当前时间的,那么系统就会设置当前时间到这个新同步回来的时间。在这种情况下,依赖于物理时间的锁逻辑(比如超时的判断等等)就是不正确的。
  2. Process pause:得到锁的节点,它的运行是有可能被阻塞的。比如 GC,下面这个图说的就是这个情况——client 1 一开始得到锁了,执行过程中有一个超长时间的 pause,这个 pause 导致锁超时并被强制释放,client 2 就得到锁了,之后 client 1 GC 结束,缓过来后恢复执行,它却并没有意识到,它的锁已经被剥夺了,于是 client 1 和 client 2 都得到了锁,对于数据的修改就会发生冲突。
  3. Network delay:其实原理和上面差不多,网络延迟+锁超时被强制剥夺和重分配的逻辑,在特定情况下就是不正确的。

问题可以理解,可是仔细想想这个问题的本质是什么?它的本质其实就是消息延迟+重排序的问题,或者更本质地说,就是分布式系统不同节点保持 consistency 的问题,因为 lock service 和 client 就是不同的节点,lock service 认为之前的锁过期了,并重分配锁给了 client 2,并且 client 2 也是这样认为的,可是 client 1 却不是,它在 GC 之后认为它还持有者锁呢。

如果我们把数据的写操作和锁管理的操作彻底分开,这个问题就很难解决,因为两个节点不可能 “一直” 在通信,在不通信的时间段内,就可能会发生这种理解不一致的情况。但是如果我们把写操作和锁管理以某种方式联系上,那么这个问题还是可以被解决的。简单说,就是物理时钟不可靠,逻辑时钟可以解决这个问题

之后 Martin Kleppmann 提出了解决方案,他的解决方案也就是按照这个思路进行的。他的方法很简单,就是在获取锁的时候,得到一个永远递增的 token(可以被称作 “fencing token”),在执行写操作的时候,必须带上这个 token。如果 storage 看到了比当前 token 更小的 token,那么那个写操作就要被丢弃掉。

Chubby

Chubby 是 Google 的分布式锁系统,论文在这里可以找到,还有这个胶片,对于进一步理解论文很有帮助。从时间上看,它是比较早的。

Chubby 被设计成用于粗粒度的(coarse-grained)锁需求,而非细粒度(fine-grained,比如几秒钟以内的)的锁需求。对于这样一个系统,文中开始就提到 consistency 和 availablity 重要性要大过 performance,后面再次提到首要目标包括 reliability,能够应对较多数量的 clients,和易于理解的语义,而吞吐量和存储容量被列在了第二位。

Chubby 暴露一个文件系统接口,每一个文件或者文件夹都可以视作一个读写锁,文件系统和 Unix 的设计思路一致,包括命名、权限等等的设计都是基于它。这是一个很有意思的设计。

对于一致性的达成,它使用 Paxos,客户端寻找 master 和写数据都使用 quorum 的机制,保证写的时候大部分节点成功,而读的时候则是至少成功读取大部分节点(R+W>N,这个思路最早我记得是 Dynamo 的论文里面有写);如果 lock 有了变化,它还提供有通知机制,因为 poll 的成本太高。

内部实现上面,每一个 Chubby 的 cell 都是由作为 replica 的 5 个服务节点组成,它们使用 Paxos 来选举 master 和达成一致,读写都只在 master 上进行(这个看起来还是挺奢侈的,一个干活,四个看戏)。如果 master 挂掉了,在 master lease 过了以后,会重新选举。Client 根据 DNS 的解析,会访问到该 cell 里面的某一个节点,它不一定是 master,但是它会告知谁是 master。

分布式锁里面比较难处理的问题不是失败,而是无响应或者响应慢的超时问题。Chubby 采用一种租约的机制,在租约期内,不会轻易变动当前的 master 节点决定。在响应超时的时期,客户端的策略就是 “不轻举妄动”,耐心等待一段时间等服务端恢复,再不行才宣告失败:

这个图的大致意思是,第一次租约 C1 续订没有问题;第二次租约续订 C2 了之后,原来的 master 挂了,心跳请求无响应,这种情况客户端不清楚服务端的状况,就比较难处理,于是它只能暂时先阻塞所有的操作,等到 C2 过期了之后,有一个 grace period;接着再 grace period 之内,新的 master 被选举出来了,心跳就恢复了,之后租约续订的 C3 顺利进行。

这显然是一个异常情形,但是一旦这种情况发生,系统是被 block 住的,会有非常大的延迟问题。思考一下,这种情况其实就是从原来的 master 到新的 master 转换的选举和交接期间,锁服务是 “暂停” 的。再进一步,这个事情的本质,其实就是在分布式系统中,CAP 原理告诉我们,为了保证 Consistency 和 Partition Tolerance,这里的情形下牺牲掉了 Availability;同时,为了保证 consistency,很难去兼顾 performance(latency 和 throughput)。

此外,有一个有点反直觉的设计是,Chubby 客户端是设计有缓存的。通常来讲,我们设计一个锁机制,第一印象就是使用缓存会带来复杂性,因为缓存会带来一致性的难题。不过它的解决办法是,使用租约。在租约期内,服务端的锁数据不可以被修改,如果要修改,那么就要同步阻塞操作通知所有的客户端,以让缓存全部失效(如果联系不上客户端那就要等过期了)。很多分布式系统都是采用 poll 的方案——一堆 client 去 poll 一个核心服务(资源),但是 Chubby 彻底反过来了,其中一个原因也是低 throughput 的考虑,毕竟只有一个 master 在干活。

对于前面提到的 Martin Kleppmann 谈到的那个问题,Chubby 给了两个解决方法:

  1. 一个是锁延迟,就是说,如果一切正常,那么持有锁的客户端在释放掉锁之后,另外的客户端可以立即获取锁。但是如果出现超时等等异常,这个锁必须被空置一段时间才可以被分配。这个方法可以降低这个问题出现的概率,但是不能彻底规避问题。
  2. 第二个就是使用序列号了,对于写入操作来说,如果请求携带的序列号要小于前一次写入的序列号,那就丢弃请求,返回失败。

回过头思考 Chubby 的实现机制,我觉得有这样几个启发:

  1. 不要相信任何 “人”(节点),必须询问到多数人(quorum),多数人的结论才可以认为是正确的。这个方式发生在很多操作上,比如寻找 master,比如选举 master,比如写数据。
  2. 超时是很难处理的,它采用了租约的机制保证节点丢失时间的上限,使用 grace period 来容忍 master 选举发生的时延,使用序列号来保证正确性。

《四火的唠叨》文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接

❌