Fan-out / fan-in 指的是一种并发模式：将工作拆分为多个单元并行执行，然后在所有任务完成后进行同步。虽然它经常在无服务器（serverless）函数的语境中被提及，但这一概念并不局限于无服务器架构。 更广义地说，fan-out / fan-in 是一种通用的并发模式，适用于任何可以将任务分解为相互独立部分的场景，例如线程、进程、Actor、微服务，甚至分布式作业，并在之后将结果汇聚起来。其核心思想是在执行阶段将工作并行展开（fan-out），在收敛阶段对各个分支的输出进行协调和聚合（fan-in），而不依赖于具体的执行模型或底层基础设施。 [caption id="attachment_70812" align="alignnone" width="1653"] Fan-out / fan-in 指的是一种并发模式：将工作拆分为多个单元并行执行，然后在所有任务完成后进行同步。[/caption] 在实际工程中，fan-out / fan-in 模式常用于提升系统吞吐量和资源利用率，尤其适合 I/O 密集型或可并行计算的场景。通过将一个复杂任务拆分为多个相互独立的子任务并同时执行，可以显著缩短整体处理时间；而在 fan-in 阶段，对各个子任务的结果进行统一汇总、排序或合并，则有助于保持业务逻辑的完整性与一致性。不过，这种模式也需要注意并发控制、错误处理以及超时与重试机制，否则容易在高并发场景下引入资源争用、级联失败或结果不一致等问题。因此，在设计和实现 fan-out / fan-in 架构时，应结合具体场景权衡并发度、系统复杂度与稳定性。 [show_file file="/var/www/wp-post-common/justyy.com/design.php"] 英文：System Design: Fan-out/Fan-in Concurrency Pattern

使用原子 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++

作为人类，我不太愿意接受「大脑是单线程的」。但是很多时候我盘算着要做甲乙丙丁好多件事，但是最终发现只能一件一件去做，怎么解释？

这十来天我一直在做一款游戏。做游戏，怎么理解都可以，构思、编写、制作一款游戏，同时这个过程对我来说也是在做游戏，玩游戏。因为水平太差，一开始倒算平稳推进，但是到了这个游戏有了世界、人物、地图之类的功能划分，就时常在关闭程序时卡住，我把错误日志复制出来去查原因，发现是一种叫做死锁的问题。意思大致上就是，为了防止一个人物增加游戏世界里的某个物品数量时，另一个人物减少同一物品，没法清算到底结果是多少，所以给这个物品加了个锁，要增减都得先开拿到锁，把自己锁在里面才能操作，免得这个时候别人篡改数据。但是问题就是复杂逻辑里，有许多数据变动是嵌套的，最终导致：一个人把甲锁住，打算修改完乙才解锁；与此同时另一个人则是锁住了乙，打算修改完甲才解锁乙。两人僵持不下，谁也动不了。

上述例子里的人，就是所谓线程，设计合理的线程应该并行不悖。锁尽量开小一些，操作什么数据就只锁住那一个数据……总之，如果不愿意接受大脑是单线程的，大概就只能接受，大脑进化得不够好，锁太大，在思考游戏如何设计时，就完全无法同时完成博客构思。两件事的思绪其实同时都在飞，但是妳选择游戏这个线程，就同时锁住了思绪「产生、梳理、记录」三个区域，其他思绪可能还会随时迸发出来，但是迸发然后消散，总是无法完成最终想要的那个成品。这很让人恼火，但是，事情还是只能一件一件去做。

fin.