ngx_shmtx_lock采用“自旋+事件唤醒”机制实现共享内存互斥：先原子CAS抢锁，失败则自旋指定次数，超时后挂起进程；解锁时置lock为0并异步唤醒等待者。

要理解 Nginx 源码中 ngx_shmtx_lock 的执行序列，核心是抓住它在共享内存（shared memory）场景下如何实现“轻量级自旋锁 + 进程间同步”的协作逻辑。它不依赖系统 mutex 或信号量，而是用一个原子变量（lock 字段）配合 CPU 自旋 + 事件唤醒机制，在多 worker 进程争抢同一块共享内存资源时保证互斥。

锁结构体与共享内存布局是前提

Nginx 的共享内存锁基于 ngx_shmtx_t 结构，通常嵌入在共享内存区（如 ngx_slab_pool_t 开头或模块自定义的 shm 区）中。关键字段包括：

• lock：指向一个 uint32_t *，即实际的锁变量地址（值为 0 表示空闲，1 表示已加锁）
• log：用于错误日志上下文
• sem（仅限支持信号量的平台）：备用阻塞机制，Linux 下通常不用
• spin：自旋次数上限（如 ngx_cacheline_size * 2048），防止空转过久

注意：该锁必须被所有 worker 进程映射到**同一虚拟地址**（通过 mmap(MAP_FIXED) 或 slab 分配器保证），否则 *lock 指向不同物理内存，同步失效。

ngx_shmtx_lock 的典型执行流程

调用 ngx_shmtx_lock(&shm->mutex) 后，主要走以下路径（以非信号量模式、Linux x86-64 为例）：

• 先尝试原子 CAS（ngx_atomic_cmp_set）将 *lock 从 0 设为 1；成功则立即返回，获得锁
• 失败则进入自旋循环：每次循环做两件事：
    – 调用 ngx_cpu_pause()（对应 pause 指令），降低功耗并提示 CPU 当前是忙等待
    – 检查自旋计数是否超限（spin-- ）；未超限则继续 CAS 尝试
• 自旋耗尽后，若仍没抢到锁，则调用 ngx_shmtx_wait() —— 此时才真正挂起当前进程：
    – 将当前进程的 epoll_event（或 kqueue 等）注册到一个“伪就绪事件”上（本质是利用 event loop 的 wait 机制模拟阻塞）
    – 实际不写 fd，而是靠锁释放时主动调用 ngx_post_event() 唤醒等待队列中的进程

锁释放 ngx_shmtx_unlock 如何触发唤醒

ngx_shmtx_unlock 不只是把 *lock = 0，关键还在于通知等待者：

• 先原子地将 *lock 置为 0
• 检查是否有进程在等待（wait != NULL）；若有，则调用 ngx_event_process_post() 把唤醒事件插入当前 cycle 的 post 队列
• 在下一个 event loop 迭代开始前，post 队列被处理，对应 worker 的 ngx_shmtx_wake() 被调用，将其从等待状态移出，重新尝试获取锁

这种“自旋 → 事件挂起 → 异步唤醒”设计，平衡了低争用下的零延迟和高争用下的 CPU 友好性。

调试与验证的小技巧

想确认某处是否真走到了等待路径，可在源码中临时加日志（如 ngx_log_debug0）：

• 在 ngx_shmtx_wait 入口打点，观察是否频繁进入（说明锁争用严重）
• 在 ngx_shmtx_unlock 中打印 wait ? "waking" : "no waiter"
• 用 gdb attach 到 worker 进程，断点设在 ngx_shmtx_lock，查看 $rax（CAS 返回值）和 *lock 内存值变化

注意：生产环境避免加日志，因其本身会加剧锁竞争；调试建议用单 worker（worker_processes 1）复现逻辑，再逐步放开。