相较于互斥对象(Mutex)和临界区对象(Critical Section) ,信号量没有所有者,它们只有计数。
ReleaseSemaphore 函数将会以指定的数量增加对应信号量对象的计数。 (增加计数这个动作,可能会释放正在等待的线程)但是释放信号量的线程不必与最初声明它的线程相同。这与互斥对象和临界区对象不同,后者要求声明线程也是释放线程。
有些人以类似互斥对象的方式使用信号量: 他们创建一个初始计数为 1 的信号量,并像这样使用它,如下面代码所示:
WaitForSingleObject(hSemaphore, INFINITE);
… do stuff ..
ReleaseSemaphore(hSemaphore, 1, NULL);
如果线程在设法释放信号量之前退出(或崩溃),则信号量计数器不会自动还原。相较于互斥对象,如果所有者线程在持有互斥对象时终止,则释放互斥对象。因此,对于这种使用模式,使用互斥对象更加合适一些。
如果资源的概念所有权可以跨线程,则信号量非常有用。我们来看下图:
此技巧不适用于互斥对象或临界区对象,因为互斥对象和临界区对象具有所有者,并且只有所有者才能释放互斥对象或临界区对象。
请注意,如果 KeepWorking 函数退出并忘记释放信号量,则计数器不会自动恢复。操作系统不知道信号量”属于”该工作项。
信号量的另一种常见用法模式与资源保护模式相反:它是资源生成模式。在此模型中,信号量计数通常为零,但在有工作要完成时递增。
请注意,在这种情况下,甚至没有信号量的概念”所有者”,除非你将工作项本身(位于工作列表数据结构上的某处)视为所有者。如果 ProcessWork 线程退出,则不希望自动释放信号量,那会破坏掉内部计数。在这种情况下,信号量是合适的对象。
(生产者/使用者信号量的更高性能版本是 I/O 完成端口。)
总结
既然提到了所谓的高性能版本,我想原作者所表达的意思是:对于尔等 C++ 工人来说,平常使用无妨,但是如果是性能攸关的代码,频繁地切换内核上下文所带来的性能开销,不可小视。