1. 从“锁”到“信号量”并发编程中的资源计数革命如果你写过C多线程程序大概率用过std::mutex和std::condition_variable。它们像是一对黄金搭档一个负责上锁一个负责等待条件成熟。但不知道你有没有遇到过这样的场景你需要控制同时访问某个资源的线程数量比如一个连接池最多允许10个连接或者一个任务队列最多允许5个线程同时处理。用mutex和condition_variable来实现这个“计数”功能代码会变得异常臃肿和容易出错。你需要手动维护一个计数器在wait和notify的逻辑里小心翼翼地增减稍有不慎就会陷入死锁或者资源泄漏。这正是C20引入std::counting_semaphore和std::binary_semaphore要解决的核心痛点。信号量Semaphore并不是一个新概念它在操作系统和计算机科学领域已经存在了几十年是并发编程的经典原语之一。但在C标准库中它却姗姗来迟直到C20才正式加入。这背后反映的是C标准库在并发原语上从“基础互斥”到“高级同步”的演进。semaphore提供了一种更直观、更安全的方式来管理对有限数量资源的并发访问它本质上是一个非负整数的计数器配合两个原子操作acquire等待并减少计数和release增加计数并可能唤醒等待者。简单来说mutex是“独占锁”同一时刻只允许一个线程进入临界区而semaphore是“通行证”它允许最多N个线程同时持有“通行证”去访问资源。这个N就是信号量的初始值。对于二进制信号量最大值为1它的行为很像mutex但有一个关键区别release操作可以由非“持有者”线程执行这为一些特定的同步模式打开了大门。在接下来的内容里我会带你彻底搞懂C20信号量的设计、用法、内部原理以及在实际项目中如何用它替换那些笨重的mutexcondition_variable组合让你的并发代码既简洁又健壮。2.std::counting_semaphore的核心接口与语义剖析std::counting_semaphore是一个模板类但它非常特殊它只有一个非类型模板参数。它的完整声明在semaphore头文件中templatestd::ptrdiff_t LeastMaxValue /* implementation-defined */ class counting_semaphore;这里的LeastMaxValue是一个编译期常量它表示这个信号量实例至少能够支持的最大计数值。注意是“至少”实际实现可能支持更大的值但不会小于它。标准库通常会提供一个默认值这个值足够大能满足绝大多数场景。所以在大多数情况下你直接使用std::counting_semaphore就足够了无需关心这个模板参数。信号量的核心状态就是一个计数器其值在0到LeastMaxValue或实现支持的最大值之间。所有操作都围绕这个计数器展开。2.1 构造函数与初始化// (1) 默认构造函数C20起 explicit counting_semaphore(std::ptrdiff_t desired 0); // (2) 删除拷贝构造和赋值 counting_semaphore(const counting_semaphore) delete; counting_semaphore operator(const counting_semaphore) delete;构造函数接受一个desired参数用于设置信号量的初始计数值。这个值必须是非负数且不能超过信号量的最大值。这里有一个非常重要的细节初始值代表的是“可用的资源数”而不是“正在等待的线程数”。例如你有一个包含5个连接的数据连接池那么信号量的初始值就应该设为5表示一开始有5个空闲连接可供获取。默认构造参数为0会创建一个初始值为0的信号量这意味着没有任何资源可用任何调用acquire()的线程都会阻塞直到其他线程调用release()。这种模式常用于线程间的“汇合”或“启动门闩”场景。2.2 资源获取acquire(),try_acquire(),try_acquire_for(),try_acquire_until()这是信号量的“消费”侧接口线程通过它们来请求资源。void acquire();这是最基础的阻塞式获取。它的语义是如果当前内部计数器大于0则将其减1然后函数立即返回线程成功获得资源。如果计数器等于0则调用线程会被阻塞直到其他线程调用release()增加计数器并且该线程被成功唤醒并减1为止。这个操作是原子的并且与所有其他acquire和release操作同步保证了计数的正确性。bool try_acquire() noexcept;非阻塞尝试。如果当前计数器大于0则将其减1并返回true否则立即返回false线程不会阻塞。这适用于“有资源就用没有就做别的事”的场景。bool try_acquire_for(const std::chrono::durationRep, Period rel_time);bool try_acquire_until(const std::chrono::time_pointClock, Duration abs_time);这两个是带超时的尝试获取。它们会在指定的相对时间或绝对时间点之前尝试进行acquire操作。如果在超时前成功获取资源返回true如果超时则返回false。这对于防止线程无限期阻塞、构建响应式系统至关重要。例如一个网络服务线程在等待任务时可以设置一个超时以便定期检查是否需要优雅关闭。注意acquire()可能会因为中断虽然C标准线程库不直接支持或虚假唤醒spurious wakeup而返回但标准保证acquire()只在计数器真正大于0时才会成功返回并减1。底层实现通常基于atomic和condition_variable会处理好这些边界情况。2.3 资源释放release()void release(std::ptrdiff_t update 1);这是信号量的“生产”侧接口。它将信号量的计数器增加update默认为1。这个增加操作是原子的。最关键的一点是release操作会唤醒正在acquire中阻塞的线程。如果有多个线程在等待具体唤醒哪一个或哪几个标准没有规定由实现决定通常是公平的或近似公平的调度。但可以确定的是被唤醒的线程会成功地将计数器减1。update参数允许一次释放多个“单位”的资源。例如一个批量处理任务完成后一次性归还多个处理槽位。但必须确保增加后的计数器不超过信号量的最大值否则行为是未定义的通常会抛出异常或终止程序。2.4 常量查询max()static constexpr std::ptrdiff_t max() noexcept;这个静态成员函数返回该信号量类型可能支持的最大计数值。对于std::counting_semaphore它返回的就是实现定义的最大值通常是一个很大的数比如PTRDIFF_MAX。你可以在设计时用它来检查你的初始值或释放值是否合法。3.std::binary_semaphore一个特化的便利工具std::binary_semaphore并不是一个独立的类它只是std::counting_semaphore的一个类型别名using binary_semaphore std::counting_semaphore1;这意味着二进制信号量的最大计数值为1。它的状态只有两种0不可用/已锁定和1可用/未锁定。这很容易让人联想到std::mutex。确实它们都可以用来实现互斥访问。但是有一个根本性的区别我称之为“所有权”语义。std::mutex具有严格的“所有权”ownership概念必须由锁定的线程来解锁。尝试在其他线程解锁一个mutex会导致未定义行为。std::binary_semaphore没有“所有权”概念任何线程都可以调用release()无论它是否调用过acquire()。这使得二进制信号量更像一个简单的“开关”或“门闩”latch而不是一个锁。这个区别决定了它们的适用场景用mutex保护临界区实现“读写互斥”。用binary_semaphore实现线程间的简单信号通知或者实现“生产者-消费者”模式中的单槽缓冲同步。例如线程A完成初始化后release()线程B在acquire()处等待这个初始化完成的信号。4. 实战对比用信号量重构经典并发模式理论说再多不如看代码。我们来看几个具体例子对比使用传统方法和C20信号量的实现。4.1 场景一限制并发线程数线程池限流假设我们有一个任务它会派发大量子任务到线程池但我们不希望同时运行的任务超过4个以免过度消耗系统资源。传统实现使用mutex和condition_variableclass ThreadLimiter { std::mutex mtx; std::condition_variable cv; int active_threads 0; const int max_threads 4; public: void enter() { std::unique_lockstd::mutex lock(mtx); cv.wait(lock, [this]{ return active_threads max_threads; }); active_threads; } void exit() { std::unique_lockstd::mutex lock(mtx); --active_threads; lock.unlock(); cv.notify_one(); // 可能唤醒多个等待者但条件检查保证了正确性 } };C20 信号量实现class ThreadLimiter { std::counting_semaphore sem{4}; // 初始有4个“许可” public: void enter() { sem.acquire(); } // 获取一个许可 void exit() { sem.release(); } // 归还一个许可 };对比之下高下立判。信号量版本代码量减少了70%逻辑一目了然初始4个许可enter时拿走一个如果没有就等exit时放回一个。完全不需要手动管理计数器也不需要condition_variable和那个容易写错的条件谓词[this]{ return active_threads max_threads; }。信号量内部已经封装了所有这些复杂的同步逻辑。4.2 场景二生产者-消费者模型有界缓冲区这是并发编程的经典问题。一个或多个生产者生产数据放入缓冲区一个或多个消费者从缓冲区取出数据。缓冲区容量有限。传统实现需要两个condition_variable一个通知“非满”一个通知“非空”一个mutex以及头尾索引和计数器代码相当复杂。C20 信号量实现templatetypename T, std::size_t BufSize class BoundedBuffer { std::arrayT, BufSize buffer; std::size_t head 0; // 消费者位置 std::size_t tail 0; // 生产者位置 std::mutex mtx; // 保护head/tail/buffer的访问 // 信号量空槽位数量 已填充项目数量 std::counting_semaphore empty_slots{BufSize}; // 初始时所有槽位都空 std::counting_semaphore filled_items{0}; // 初始时没有项目 public: void push(const T item) { empty_slots.acquire(); // 等待有空槽位 { std::lock_guardstd::mutex lock(mtx); buffer[tail] item; tail (tail 1) % BufSize; } filled_items.release(); // 通知消费者有新项目 } T pop() { filled_items.acquire(); // 等待有项目可消费 T item; { std::lock_guardstd::mutex lock(mtx); item buffer[head]; head (head 1) % BufSize; } empty_slots.release(); // 通知生产者空出一个槽位 return item; } };这个实现非常优雅。两个信号量分别管理两种资源“空槽位”和“已填充项”。push操作首先申请一个“空槽位”资源然后操作缓冲区最后生产一个“已填充项”资源。pop操作则相反。mutex只用来保护对缓冲区数组和索引的并发修改其临界区非常小。这种“信号量负责同步互斥锁负责互斥”的分离设计清晰且高效。4.3 场景三线程汇合点多阶段任务同步有时我们需要多个线程分阶段工作并且在一个阶段所有线程完成后才能一起进入下一个阶段。std::counting_semaphore phase1_done{0}; // 第一阶段完成信号 std::counting_semaphore phase2_ready{0}; // 第二阶段准备信号 void worker_thread(int id) { // 第一阶段工作 std::this_thread::sleep_for(std::chrono::milliseconds(100 * id)); std::cout Worker id finished phase 1.\n; // 通知主线程自己已完成第一阶段 phase1_done.release(); // 等待主线程发出第二阶段开始信号 phase2_ready.acquire(); // 第二阶段工作 std::cout Worker id started phase 2.\n; } int main() { constexpr int num_workers 5; std::vectorstd::jthread workers; workers.reserve(num_workers); for (int i 0; i num_workers; i) { workers.emplace_back(worker_thread, i); } // 主线程等待所有工作线程完成第一阶段 for (int i 0; i num_workers; i) { phase1_done.acquire(); // 获取5次代表5个线程都完成了 } std::cout All workers finished phase 1. Starting phase 2...\n; // 主线程释放信号让所有工作线程同时开始第二阶段 phase2_ready.release(num_workers); // 一次性释放5个许可 // workers析构时会自动join return 0; }在这个例子中phase1_done信号量被工作者线程release被主线程acquire用于收集所有线程完成第一阶段的通知。phase2_ready信号量则相反由主线程一次性release多个许可所有工作者线程同时acquire到许可后开始第二阶段实现了“发令枪”的效果。这种模式用condition_variable实现会麻烦很多需要仔细管理计数器。5. 深入原理信号量是如何实现的虽然标准没有规定具体的实现方式但我们可以探讨一个基于std::atomic和std::condition_variable的典型、正确的实现思路这有助于理解其语义和性能特征。// 简化的 counting_semaphore 实现思路非标准库代码 class naive_counting_semaphore { std::atomicstd::ptrdiff_t count; std::mutex mtx; std::condition_variable cv; const std::ptrdiff_t max_val; public: explicit naive_counting_semaphore(std::ptrdiff_t desired 0, std::ptrdiff_t max SEM_MAX) : count(desired), max_val(max) {} void acquire() { std::unique_lockstd::mutex lock(mtx); // 必须使用循环处理虚假唤醒 cv.wait(lock, [this]{ return count.load(std::memory_order_relaxed) 0; }); count.fetch_sub(1, std::memory_order_relaxed); } bool try_acquire() { std::ptrdiff_t old count.load(std::memory_order_relaxed); while (old 0) { if (count.compare_exchange_weak(old, old - 1, std::memory_order_acquire, std::memory_order_relaxed)) { return true; } } return false; } void release(std::ptrdiff_t update 1) { { std::lock_guardstd::mutex lock(mtx); std::ptrdiff_t new_val count.fetch_add(update, std::memory_order_relaxed) update; if (new_val max_val) { /* 处理溢出通常抛异常 */ } } // 通知等待的线程。这里可以优化如果update1可以notify_all或者根据等待线程数通知。 if (update 1) { cv.notify_one(); } else { cv.notify_all(); } } };从这个简化实现中我们可以看出几个关键点计数器是原子的acquire中的减1和release中的加1都需要在互斥锁保护下与条件变量的等待/通知正确同步或者像try_acquire那样使用原子操作的无锁实现。标准库的实现无疑会进行高度优化。acquire()是阻塞的它通过condition_variable::wait实现这意味着线程会让出CPU进入休眠状态直到被notify。这适用于等待时间可能较长的场景。try_acquire()通常是无锁的它使用compare_exchange_weak循环一种常见的原子操作模式来尝试减少计数器。如果成功它使用memory_order_acquire语义确保之后对共享资源的读写能看到release线程之前的所有写入。如果失败计数器为0它立即返回不会阻塞。这使其性能非常高。release()需要锁在增加计数器时需要锁来与acquire()中的wait正确配合。增加后根据情况调用notify_one()或notify_all()。标准库实现可能会根据等待队列的长度进行智能通知。性能考量由于acquire()和release()可能涉及锁和系统调用它们比单纯的原子操作要重。因此在超高并发、竞争激烈的场景下如果资源争用频繁信号量可能成为性能瓶颈。此时可能需要考虑无锁队列或其他更高级的并发结构。但对于大多数应用层级的并发控制信号量的性能是完全足够的其带来的代码简洁性和正确性提升是巨大的。6. 避坑指南与最佳实践在实际项目中使用信号量有几个陷阱需要特别注意。陷阱一初始值设反这是最常见的错误。记住信号量的值代表“可用资源数”。如果你想控制最大并发数为N那么初始值就是N你有N个空闲资源。线程acquire()是消耗资源release()是归还资源。如果你错误地设为0那么所有线程一开始就会阻塞在acquire()上形成死锁。陷阱二忘记释放资源泄漏和动态内存一样信号量的“许可”也是一种资源。每个acquire()都必须对应一个release()通常使用RAII资源获取即初始化技术来保证。C标准库没有提供std::lock_guard或std::unique_lock对信号量的直接支持但我们可以自己实现一个class semaphore_guard { std::counting_semaphore sem; public: explicit semaphore_guard(std::counting_semaphore s) : sem(s) { sem.acquire(); } ~semaphore_guard() { sem.release(); } // 禁止拷贝和移动 semaphore_guard(const semaphore_guard) delete; semaphore_guard operator(const semaphore_guard) delete; }; // 使用方式 { semaphore_guard guard(my_semaphore); // 构造时acquire // ... 访问受保护的资源 ... } // 析构时自动release陷阱三将二进制信号量完全等同于互斥锁如前所述binary_semaphore没有所有权。考虑以下错误代码std::binary_semaphore bsem{1}; void bad_use() { bsem.acquire(); // ... 临界区代码 ... // 假设这里发生异常提前返回或抛出异常 bsem.release(); // 可能不会被执行 }如果临界区代码抛出异常release()将不会被调用导致信号量永远处于锁定状态值为0其他所有线程都会在acquire()上永久阻塞。而std::unique_lockstd::mutex在异常发生时其析构函数会自动解锁互斥量。因此如果你需要的是严格的、作用域化的互斥锁请坚持使用std::mutex和std::lock_guard/std::unique_lock。二进制信号量更适合用于信号通知。最佳实践建议优先选择counting_semaphore除非你明确需要一个最大值为1的计数器否则直接使用std::counting_semaphore。它的语义更通用。用于“资源计数”场景信号量最自然的用途就是管理有限数量的同类资源线程池槽位、数据库连接、网络连接、IO缓冲区等。与mutex分工合作在生产者-消费者等模式中用信号量管理“空/满”状态用mutex保护实际数据结构的内部一致性。各司其职代码清晰。善用try_acquire_for进行超时控制在可能长时间等待或需要响应外部事件如关闭信号的地方总是使用超时版本避免线程“饿死”或无法优雅退出。理解内存序信号量的acquire/release操作建立了线程间的同步关系类似于mutex的锁/解锁它们隐式地包含了std::memory_order_acquire和std::memory_order_release语义。这意味着通过信号量同步的线程对共享数据的读写具有正确的可见性。7. 信号量在现代C并发工具箱中的定位C11引入了std::mutex,std::condition_variable,std::atomic等基础并发组件。C20则进一步丰富了这一工具箱加入了std::counting_semaphore,std::binary_semaphore,std::latch,std::barrier等更高级的同步原语。std::latch一次性使用的倒计时门闩。初始化一个计数线程可以count_down或wait当计数减到0时所有等待的线程被释放。它非常适合“等待多个初始化任务完成”的场景并且count_down可以由任意线程调用任意次数。信号量也可以模拟latch但latch的“一次性”语义更精确。std::barrier可重复使用的线程屏障。一组线程数量固定在屏障点等待直到所有线程都到达然后一起释放并且可以自动执行一个完成函数。它适用于多阶段并行计算。信号量实现类似功能需要更复杂的逻辑。信号量在其中扮演了一个灵活的资源计数器角色。它比latch和barrier更基础可以用来构建它们尽管可能效率不如专用实现。它的核心优势在于对“N个可用资源”这一抽象的直接建模。当你需要管理一个池子或者需要在线程间传递“可用性”信号并且这个信号有明确的“数量”概念时std::counting_semaphore应该是你的首选工具。它用极简的API封装了复杂的同步逻辑极大地减少了手动使用mutex和condition_variable时容易出现的竞态条件和死锁错误。从我个人的项目经验来看自从C20普及后代码库中那些手写的、基于condition_variable的“简陋信号量”都被替换成了std::counting_semaphore。代码行数减少了逻辑清晰了团队新成员也更容易理解同步的意图。虽然底层性能差异不大但开发效率和代码维护性的提升是实实在在的。如果你还在使用C17或更早的标准可能需要自己实现或借助第三方库但如果你的项目已经升级到C20那么是时候让这个强大的新工具为你服务了。
1. 从“锁”到“信号量”并发编程中的资源计数革命如果你写过C多线程程序大概率用过std::mutex和std::condition_variable。它们像是一对黄金搭档一个负责上锁一个负责等待条件成熟。但不知道你有没有遇到过这样的场景你需要控制同时访问某个资源的线程数量比如一个连接池最多允许10个连接或者一个任务队列最多允许5个线程同时处理。用mutex和condition_variable来实现这个“计数”功能代码会变得异常臃肿和容易出错。你需要手动维护一个计数器在wait和notify的逻辑里小心翼翼地增减稍有不慎就会陷入死锁或者资源泄漏。这正是C20引入std::counting_semaphore和std::binary_semaphore要解决的核心痛点。信号量Semaphore并不是一个新概念它在操作系统和计算机科学领域已经存在了几十年是并发编程的经典原语之一。但在C标准库中它却姗姗来迟直到C20才正式加入。这背后反映的是C标准库在并发原语上从“基础互斥”到“高级同步”的演进。semaphore提供了一种更直观、更安全的方式来管理对有限数量资源的并发访问它本质上是一个非负整数的计数器配合两个原子操作acquire等待并减少计数和release增加计数并可能唤醒等待者。简单来说mutex是“独占锁”同一时刻只允许一个线程进入临界区而semaphore是“通行证”它允许最多N个线程同时持有“通行证”去访问资源。这个N就是信号量的初始值。对于二进制信号量最大值为1它的行为很像mutex但有一个关键区别release操作可以由非“持有者”线程执行这为一些特定的同步模式打开了大门。在接下来的内容里我会带你彻底搞懂C20信号量的设计、用法、内部原理以及在实际项目中如何用它替换那些笨重的mutexcondition_variable组合让你的并发代码既简洁又健壮。2.std::counting_semaphore的核心接口与语义剖析std::counting_semaphore是一个模板类但它非常特殊它只有一个非类型模板参数。它的完整声明在semaphore头文件中templatestd::ptrdiff_t LeastMaxValue /* implementation-defined */ class counting_semaphore;这里的LeastMaxValue是一个编译期常量它表示这个信号量实例至少能够支持的最大计数值。注意是“至少”实际实现可能支持更大的值但不会小于它。标准库通常会提供一个默认值这个值足够大能满足绝大多数场景。所以在大多数情况下你直接使用std::counting_semaphore就足够了无需关心这个模板参数。信号量的核心状态就是一个计数器其值在0到LeastMaxValue或实现支持的最大值之间。所有操作都围绕这个计数器展开。2.1 构造函数与初始化// (1) 默认构造函数C20起 explicit counting_semaphore(std::ptrdiff_t desired 0); // (2) 删除拷贝构造和赋值 counting_semaphore(const counting_semaphore) delete; counting_semaphore operator(const counting_semaphore) delete;构造函数接受一个desired参数用于设置信号量的初始计数值。这个值必须是非负数且不能超过信号量的最大值。这里有一个非常重要的细节初始值代表的是“可用的资源数”而不是“正在等待的线程数”。例如你有一个包含5个连接的数据连接池那么信号量的初始值就应该设为5表示一开始有5个空闲连接可供获取。默认构造参数为0会创建一个初始值为0的信号量这意味着没有任何资源可用任何调用acquire()的线程都会阻塞直到其他线程调用release()。这种模式常用于线程间的“汇合”或“启动门闩”场景。2.2 资源获取acquire(),try_acquire(),try_acquire_for(),try_acquire_until()这是信号量的“消费”侧接口线程通过它们来请求资源。void acquire();这是最基础的阻塞式获取。它的语义是如果当前内部计数器大于0则将其减1然后函数立即返回线程成功获得资源。如果计数器等于0则调用线程会被阻塞直到其他线程调用release()增加计数器并且该线程被成功唤醒并减1为止。这个操作是原子的并且与所有其他acquire和release操作同步保证了计数的正确性。bool try_acquire() noexcept;非阻塞尝试。如果当前计数器大于0则将其减1并返回true否则立即返回false线程不会阻塞。这适用于“有资源就用没有就做别的事”的场景。bool try_acquire_for(const std::chrono::durationRep, Period rel_time);bool try_acquire_until(const std::chrono::time_pointClock, Duration abs_time);这两个是带超时的尝试获取。它们会在指定的相对时间或绝对时间点之前尝试进行acquire操作。如果在超时前成功获取资源返回true如果超时则返回false。这对于防止线程无限期阻塞、构建响应式系统至关重要。例如一个网络服务线程在等待任务时可以设置一个超时以便定期检查是否需要优雅关闭。注意acquire()可能会因为中断虽然C标准线程库不直接支持或虚假唤醒spurious wakeup而返回但标准保证acquire()只在计数器真正大于0时才会成功返回并减1。底层实现通常基于atomic和condition_variable会处理好这些边界情况。2.3 资源释放release()void release(std::ptrdiff_t update 1);这是信号量的“生产”侧接口。它将信号量的计数器增加update默认为1。这个增加操作是原子的。最关键的一点是release操作会唤醒正在acquire中阻塞的线程。如果有多个线程在等待具体唤醒哪一个或哪几个标准没有规定由实现决定通常是公平的或近似公平的调度。但可以确定的是被唤醒的线程会成功地将计数器减1。update参数允许一次释放多个“单位”的资源。例如一个批量处理任务完成后一次性归还多个处理槽位。但必须确保增加后的计数器不超过信号量的最大值否则行为是未定义的通常会抛出异常或终止程序。2.4 常量查询max()static constexpr std::ptrdiff_t max() noexcept;这个静态成员函数返回该信号量类型可能支持的最大计数值。对于std::counting_semaphore它返回的就是实现定义的最大值通常是一个很大的数比如PTRDIFF_MAX。你可以在设计时用它来检查你的初始值或释放值是否合法。3.std::binary_semaphore一个特化的便利工具std::binary_semaphore并不是一个独立的类它只是std::counting_semaphore的一个类型别名using binary_semaphore std::counting_semaphore1;这意味着二进制信号量的最大计数值为1。它的状态只有两种0不可用/已锁定和1可用/未锁定。这很容易让人联想到std::mutex。确实它们都可以用来实现互斥访问。但是有一个根本性的区别我称之为“所有权”语义。std::mutex具有严格的“所有权”ownership概念必须由锁定的线程来解锁。尝试在其他线程解锁一个mutex会导致未定义行为。std::binary_semaphore没有“所有权”概念任何线程都可以调用release()无论它是否调用过acquire()。这使得二进制信号量更像一个简单的“开关”或“门闩”latch而不是一个锁。这个区别决定了它们的适用场景用mutex保护临界区实现“读写互斥”。用binary_semaphore实现线程间的简单信号通知或者实现“生产者-消费者”模式中的单槽缓冲同步。例如线程A完成初始化后release()线程B在acquire()处等待这个初始化完成的信号。4. 实战对比用信号量重构经典并发模式理论说再多不如看代码。我们来看几个具体例子对比使用传统方法和C20信号量的实现。4.1 场景一限制并发线程数线程池限流假设我们有一个任务它会派发大量子任务到线程池但我们不希望同时运行的任务超过4个以免过度消耗系统资源。传统实现使用mutex和condition_variableclass ThreadLimiter { std::mutex mtx; std::condition_variable cv; int active_threads 0; const int max_threads 4; public: void enter() { std::unique_lockstd::mutex lock(mtx); cv.wait(lock, [this]{ return active_threads max_threads; }); active_threads; } void exit() { std::unique_lockstd::mutex lock(mtx); --active_threads; lock.unlock(); cv.notify_one(); // 可能唤醒多个等待者但条件检查保证了正确性 } };C20 信号量实现class ThreadLimiter { std::counting_semaphore sem{4}; // 初始有4个“许可” public: void enter() { sem.acquire(); } // 获取一个许可 void exit() { sem.release(); } // 归还一个许可 };对比之下高下立判。信号量版本代码量减少了70%逻辑一目了然初始4个许可enter时拿走一个如果没有就等exit时放回一个。完全不需要手动管理计数器也不需要condition_variable和那个容易写错的条件谓词[this]{ return active_threads max_threads; }。信号量内部已经封装了所有这些复杂的同步逻辑。4.2 场景二生产者-消费者模型有界缓冲区这是并发编程的经典问题。一个或多个生产者生产数据放入缓冲区一个或多个消费者从缓冲区取出数据。缓冲区容量有限。传统实现需要两个condition_variable一个通知“非满”一个通知“非空”一个mutex以及头尾索引和计数器代码相当复杂。C20 信号量实现templatetypename T, std::size_t BufSize class BoundedBuffer { std::arrayT, BufSize buffer; std::size_t head 0; // 消费者位置 std::size_t tail 0; // 生产者位置 std::mutex mtx; // 保护head/tail/buffer的访问 // 信号量空槽位数量 已填充项目数量 std::counting_semaphore empty_slots{BufSize}; // 初始时所有槽位都空 std::counting_semaphore filled_items{0}; // 初始时没有项目 public: void push(const T item) { empty_slots.acquire(); // 等待有空槽位 { std::lock_guardstd::mutex lock(mtx); buffer[tail] item; tail (tail 1) % BufSize; } filled_items.release(); // 通知消费者有新项目 } T pop() { filled_items.acquire(); // 等待有项目可消费 T item; { std::lock_guardstd::mutex lock(mtx); item buffer[head]; head (head 1) % BufSize; } empty_slots.release(); // 通知生产者空出一个槽位 return item; } };这个实现非常优雅。两个信号量分别管理两种资源“空槽位”和“已填充项”。push操作首先申请一个“空槽位”资源然后操作缓冲区最后生产一个“已填充项”资源。pop操作则相反。mutex只用来保护对缓冲区数组和索引的并发修改其临界区非常小。这种“信号量负责同步互斥锁负责互斥”的分离设计清晰且高效。4.3 场景三线程汇合点多阶段任务同步有时我们需要多个线程分阶段工作并且在一个阶段所有线程完成后才能一起进入下一个阶段。std::counting_semaphore phase1_done{0}; // 第一阶段完成信号 std::counting_semaphore phase2_ready{0}; // 第二阶段准备信号 void worker_thread(int id) { // 第一阶段工作 std::this_thread::sleep_for(std::chrono::milliseconds(100 * id)); std::cout Worker id finished phase 1.\n; // 通知主线程自己已完成第一阶段 phase1_done.release(); // 等待主线程发出第二阶段开始信号 phase2_ready.acquire(); // 第二阶段工作 std::cout Worker id started phase 2.\n; } int main() { constexpr int num_workers 5; std::vectorstd::jthread workers; workers.reserve(num_workers); for (int i 0; i num_workers; i) { workers.emplace_back(worker_thread, i); } // 主线程等待所有工作线程完成第一阶段 for (int i 0; i num_workers; i) { phase1_done.acquire(); // 获取5次代表5个线程都完成了 } std::cout All workers finished phase 1. Starting phase 2...\n; // 主线程释放信号让所有工作线程同时开始第二阶段 phase2_ready.release(num_workers); // 一次性释放5个许可 // workers析构时会自动join return 0; }在这个例子中phase1_done信号量被工作者线程release被主线程acquire用于收集所有线程完成第一阶段的通知。phase2_ready信号量则相反由主线程一次性release多个许可所有工作者线程同时acquire到许可后开始第二阶段实现了“发令枪”的效果。这种模式用condition_variable实现会麻烦很多需要仔细管理计数器。5. 深入原理信号量是如何实现的虽然标准没有规定具体的实现方式但我们可以探讨一个基于std::atomic和std::condition_variable的典型、正确的实现思路这有助于理解其语义和性能特征。// 简化的 counting_semaphore 实现思路非标准库代码 class naive_counting_semaphore { std::atomicstd::ptrdiff_t count; std::mutex mtx; std::condition_variable cv; const std::ptrdiff_t max_val; public: explicit naive_counting_semaphore(std::ptrdiff_t desired 0, std::ptrdiff_t max SEM_MAX) : count(desired), max_val(max) {} void acquire() { std::unique_lockstd::mutex lock(mtx); // 必须使用循环处理虚假唤醒 cv.wait(lock, [this]{ return count.load(std::memory_order_relaxed) 0; }); count.fetch_sub(1, std::memory_order_relaxed); } bool try_acquire() { std::ptrdiff_t old count.load(std::memory_order_relaxed); while (old 0) { if (count.compare_exchange_weak(old, old - 1, std::memory_order_acquire, std::memory_order_relaxed)) { return true; } } return false; } void release(std::ptrdiff_t update 1) { { std::lock_guardstd::mutex lock(mtx); std::ptrdiff_t new_val count.fetch_add(update, std::memory_order_relaxed) update; if (new_val max_val) { /* 处理溢出通常抛异常 */ } } // 通知等待的线程。这里可以优化如果update1可以notify_all或者根据等待线程数通知。 if (update 1) { cv.notify_one(); } else { cv.notify_all(); } } };从这个简化实现中我们可以看出几个关键点计数器是原子的acquire中的减1和release中的加1都需要在互斥锁保护下与条件变量的等待/通知正确同步或者像try_acquire那样使用原子操作的无锁实现。标准库的实现无疑会进行高度优化。acquire()是阻塞的它通过condition_variable::wait实现这意味着线程会让出CPU进入休眠状态直到被notify。这适用于等待时间可能较长的场景。try_acquire()通常是无锁的它使用compare_exchange_weak循环一种常见的原子操作模式来尝试减少计数器。如果成功它使用memory_order_acquire语义确保之后对共享资源的读写能看到release线程之前的所有写入。如果失败计数器为0它立即返回不会阻塞。这使其性能非常高。release()需要锁在增加计数器时需要锁来与acquire()中的wait正确配合。增加后根据情况调用notify_one()或notify_all()。标准库实现可能会根据等待队列的长度进行智能通知。性能考量由于acquire()和release()可能涉及锁和系统调用它们比单纯的原子操作要重。因此在超高并发、竞争激烈的场景下如果资源争用频繁信号量可能成为性能瓶颈。此时可能需要考虑无锁队列或其他更高级的并发结构。但对于大多数应用层级的并发控制信号量的性能是完全足够的其带来的代码简洁性和正确性提升是巨大的。6. 避坑指南与最佳实践在实际项目中使用信号量有几个陷阱需要特别注意。陷阱一初始值设反这是最常见的错误。记住信号量的值代表“可用资源数”。如果你想控制最大并发数为N那么初始值就是N你有N个空闲资源。线程acquire()是消耗资源release()是归还资源。如果你错误地设为0那么所有线程一开始就会阻塞在acquire()上形成死锁。陷阱二忘记释放资源泄漏和动态内存一样信号量的“许可”也是一种资源。每个acquire()都必须对应一个release()通常使用RAII资源获取即初始化技术来保证。C标准库没有提供std::lock_guard或std::unique_lock对信号量的直接支持但我们可以自己实现一个class semaphore_guard { std::counting_semaphore sem; public: explicit semaphore_guard(std::counting_semaphore s) : sem(s) { sem.acquire(); } ~semaphore_guard() { sem.release(); } // 禁止拷贝和移动 semaphore_guard(const semaphore_guard) delete; semaphore_guard operator(const semaphore_guard) delete; }; // 使用方式 { semaphore_guard guard(my_semaphore); // 构造时acquire // ... 访问受保护的资源 ... } // 析构时自动release陷阱三将二进制信号量完全等同于互斥锁如前所述binary_semaphore没有所有权。考虑以下错误代码std::binary_semaphore bsem{1}; void bad_use() { bsem.acquire(); // ... 临界区代码 ... // 假设这里发生异常提前返回或抛出异常 bsem.release(); // 可能不会被执行 }如果临界区代码抛出异常release()将不会被调用导致信号量永远处于锁定状态值为0其他所有线程都会在acquire()上永久阻塞。而std::unique_lockstd::mutex在异常发生时其析构函数会自动解锁互斥量。因此如果你需要的是严格的、作用域化的互斥锁请坚持使用std::mutex和std::lock_guard/std::unique_lock。二进制信号量更适合用于信号通知。最佳实践建议优先选择counting_semaphore除非你明确需要一个最大值为1的计数器否则直接使用std::counting_semaphore。它的语义更通用。用于“资源计数”场景信号量最自然的用途就是管理有限数量的同类资源线程池槽位、数据库连接、网络连接、IO缓冲区等。与mutex分工合作在生产者-消费者等模式中用信号量管理“空/满”状态用mutex保护实际数据结构的内部一致性。各司其职代码清晰。善用try_acquire_for进行超时控制在可能长时间等待或需要响应外部事件如关闭信号的地方总是使用超时版本避免线程“饿死”或无法优雅退出。理解内存序信号量的acquire/release操作建立了线程间的同步关系类似于mutex的锁/解锁它们隐式地包含了std::memory_order_acquire和std::memory_order_release语义。这意味着通过信号量同步的线程对共享数据的读写具有正确的可见性。7. 信号量在现代C并发工具箱中的定位C11引入了std::mutex,std::condition_variable,std::atomic等基础并发组件。C20则进一步丰富了这一工具箱加入了std::counting_semaphore,std::binary_semaphore,std::latch,std::barrier等更高级的同步原语。std::latch一次性使用的倒计时门闩。初始化一个计数线程可以count_down或wait当计数减到0时所有等待的线程被释放。它非常适合“等待多个初始化任务完成”的场景并且count_down可以由任意线程调用任意次数。信号量也可以模拟latch但latch的“一次性”语义更精确。std::barrier可重复使用的线程屏障。一组线程数量固定在屏障点等待直到所有线程都到达然后一起释放并且可以自动执行一个完成函数。它适用于多阶段并行计算。信号量实现类似功能需要更复杂的逻辑。信号量在其中扮演了一个灵活的资源计数器角色。它比latch和barrier更基础可以用来构建它们尽管可能效率不如专用实现。它的核心优势在于对“N个可用资源”这一抽象的直接建模。当你需要管理一个池子或者需要在线程间传递“可用性”信号并且这个信号有明确的“数量”概念时std::counting_semaphore应该是你的首选工具。它用极简的API封装了复杂的同步逻辑极大地减少了手动使用mutex和condition_variable时容易出现的竞态条件和死锁错误。从我个人的项目经验来看自从C20普及后代码库中那些手写的、基于condition_variable的“简陋信号量”都被替换成了std::counting_semaphore。代码行数减少了逻辑清晰了团队新成员也更容易理解同步的意图。虽然底层性能差异不大但开发效率和代码维护性的提升是实实在在的。如果你还在使用C17或更早的标准可能需要自己实现或借助第三方库但如果你的项目已经升级到C20那么是时候让这个强大的新工具为你服务了。
