blocks|key|4542017|text|在许多情况下，获得信号量的线程不能释放它，因为它被阻塞，等待某人释放信号量，而且必须是其他线程释放(信号)信号量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4542018|在忙着等待的情况下实现信号量将是非常糟糕的。与锁不同的是，有些情况下信号保持很长时间(秒或分钟，小时可能有点不寻常，但绝对有可能)。|4542019|显然，对信号量对象的引用需要存储在另一个线程可以访问它的地方。|4542020|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

In many situations, the thread that acquired a semaphore can't release it, because it is blocked waiting for someone to release the semaphore, and it must be some other thread releasing (signalling) the semaphore. 

Implementing semaphores with busy waiting would be just absolutely awful. Unlike with locks, there are situations where semaphores are held for a long time (seconds or minutes, hours would be a bit unusual but is absolutely possible). 

Obviously a reference to the semaphore object needs to be stored in a place where another thread can access it.

blocks|key|4142845|text|信号量所涵盖的用例与互斥对象不同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4142846|有了互斥物，你就对了。互斥通常用于防止代码中关键部分的并发执行。一个特定的线程将在关键部分开始时获取互斥对象，并在它再次离开关键部分时释放它。如果一个互斥对象被另一个线程释放，这将意味着关键部分跨越多个线程，这很可能不是您想要做的事情。|4142847|信号量的用例略有不同。它指示资源的可用性。需要使用资源的线程将获得信号量，该信号量在概念上是获取底层资源。如果没有可用的资源，则获取将阻止。|4142848|现在，在我们讨论一组固定资源(如一组可用的I/O端口)的场景中，获取线程再次释放资源也是有意义的。我获得了端口，做了一些工作，并在完成时释放了它，这样其他线程就可以在它上工作了。|4142849|但这并不是信号量的唯一用例。想想生产者/消费者:生产者线程可能提供资源(就像工作线程排队处理的项目一样)，使用者线程会接受它们。在这些场景中，消耗的资源通常会消失，因此在获取资源后不会释放它们。相反，生成线程调用release以指示有可用的东西可供使用。然后，消费者调用获取来获取所产生的资源并对其进行处理。生产商永远不会呼叫收购，消费者也不会要求发布。|4142850|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

A semaphore covers different use cases than a mutex.

With a mutex, you would be right. A mutex is typically used to prevent concurrent execution of critical sections in the code. A particular thread will acquire the mutex at the start of the critical section and release it when it leaves the critical section again. Having a mutex being released by a different thread than the one that acquired it would mean that the critical section is spanned across multiple threads, which is most probably not how you want to do things.

The use case for a semaphore is slightly different. It signals availability of a resource. A thread that needs to consume a resource will acquire the semaphore, which is conceptually acquiring the underlying resource. If no resources are available, the acquire will block.

Now, in the scenario where we talk about a fixed set of resources (like a set of available I/O ports) it makes sense for the acquiring thread to also release the resource again. I acquire the port, do some work and release it when I'm done so that other threads can do work on it.

But this is not the only use case for semaphores. Think of producer/consumer: A producer thread might provide resources (like items that are queued for processing by a worker thread) and the consumer thread will accept them. In these scenarios, consumed resources are typically gone, so you do not release your resources after acquiring them. Instead, the producing thread calls release to indicate that there is stuff available for consumption. The consumer then calls acquire to claim a produced resource and process it. A producer will never call acquire and a consumer will never call release.

In <a href="https://stackoverflow.com/a/7336516/156458">Semaphore vs. Monitors - what's the difference?</a>,

<blockquote>
 The thread that releases a semaphore need not be the same thread that
 acquired it.
</blockquote>

if a thread didn't acquire a semaphore, then how can the thread release the semaphore?

Does the semaphore here mean a semaphore implemented with busy waiting, or implemented with process blocking?

Thanks.

What does it mean by 'The thread that releases a semaphore need not be the same thread that acquired it'?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在中，释放信号量的线程不一定是获得信号量的线程。如果线程没有获得信号量，那么线程如何释放信号量？这里的信号量是指在繁忙等待中实现的信号量，还是使用进程阻塞实现的信号量？谢谢。

问它所说的‘释放信号量的线程不一定是获得它的线程’是什么意思？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问它所说的‘释放信号量的线程不一定是获得它的线程’是什么意思？EN