[技术方案讨论] 如何仅使用 set、get 操作实现一个锁？

[CC11001100]

比如现在我们有一个服务，这个服务提供了两种操作：

• set(key string)
• get(key string) string 有没有办法仅基于这两种操作构造出来一个锁？

op 想了几天了也没想清楚到底咋搞，目前隐约有的几种思路：

• 使用多个 key 看看能不能组合出来
• 给 key 加版本号看能不能组合出来
• 没了...

网上找到了几个类似的解决方案，但模拟演算了半天总感觉是有问题的：
localStorage 互斥锁的使用
fast-mutex

op 之前在论坛里发过几次帖子，难的 op 想跳河的问题大佬们都是随手点拨困难烟消云散，所以就寻思着来论坛里问问，看看大佬们有啥看法

BTW: 非公司业务非盈利相关，只是笔者自己学习折腾时的一些奇奇怪怪的想法拿出来和大家讨论一下

[yinfeng]

这是非常经典的计科问题，使用任意多个，有读和写方法的，顺序一致的，原子寄存器实现互斥锁。

简单看了下 fast-mutex 用的算法，它试图用两个 SC 的原子寄存器去实现 n 个线程的互斥，假设了一个线程的延迟执行一定能使其他线程执行完 lock 的代码。问题就是如果无视这个假设很容易就能构造反例。

如果非要去做这样的事，有挺多算法可以选择，只是都很慢。最经典的就是，两线程可以用 Peterson lock ，Peterson lock 可以推广到 n 个线程叫作 filter lock ，还有具有公平性的 bakery 算法。
https://en.wikipedia.org/wiki/Peterson%27s_algorithm
https://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm

[Mistwave]

@Kumo31 确实是这样，老哥 tql
第七页：
https://pages.cs.wisc.edu/~remzi/OSTEP/threads-locks.pdf

[ysc3839]

@chesha1 exchange 实际上不会有 compare 操作，就只是交换值。只有多状态的锁(比如读写锁)才需要 compare exchange 操作。

[chesha1]

@ysc3839 还真是，我又仔细看了一眼，是我自己想错了
spin 条件判断调用了一个通用的 boost::atomic 的 exchange 方法，肯定跟模板参数的属性没关系

[nuk]

老哥可以看看这本书《多处理器编程的艺术》