信号量队列
我正在扩展信号量的功能。 当我意识到我不知道实际信号量的实现时，我遇到了障碍，为了确保我的代码正确运行，我需要知道这一点。
我知道信号量的工作原理是在调用 sem_wait() 时阻塞正在等待它的线程，而另一个线程当前已锁定它。 然后该线程被阻塞，然后放入该信号量的等待列表中。
我的问题与 sem_post() 上发生的情况有关。 下一个线程是否从等待列表中拉出，设置为锁定线程，并允许解除阻塞？ 或者发帖方案完全不同？
谢谢！
I'm extending the functionality of a semaphore. I ran into a roadblock when I realized I don't know the implementation of an actual semaphore and to make sure my code ran correctly, I needed to know this.
I know a semaphore works by blocking threads that are waiting on it when they call sem_wait() and another thread currently has it locked. The thread is then blocked and then put into a wait list for that semaphore.
My question relates to what happens on a sem_post(). Is the next thread pulled off the waiting list, set as the locking thread, and allowed to be unblocked? Or is the scheme for posting completely different?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
下一个在其
sem_wait()上解锁的线程将是操作系统决定上下文切换到的下一个线程。 没有人对订购做任何保证； 这取决于您的操作系统的调度策略。 它可能是脱离 CPU 时间最长的线程，或者被分配了最高“优先级”的线程，或者历史上具有某些资源使用统计信息的线程，等等。最有可能的是，您当前的线程（调用
sem_post()的线程）将继续运行一段时间，直到它开始等待用户输入、阻塞另一个信号量或耗尽其操作系统。分配的时间片。 然后，操作系统将切换到一些完全不相关的进程来运行一小会儿（可能是 Firefox 或其他东西），然后处理一些网络流量，给自己喝杯茶，最后，当它绕过时根据过去的历史记录是否感觉特定线程更多地受 CPU 或 I/O 限制，选择您感觉喜欢的任何其他线程。在许多操作系统中，优先级会优先考虑出现时间不长的 I/O 密集型进程。 理论上来说，新的进程可能是短暂的（如果它已经存在了五个小时，那么它很可能不会在接下来的 1 毫秒内完成），所以我们不妨结束它们。 I/O 密集型进程可能会继续是 I/O 密集型，这意味着它们很可能会在等待其他资源时很快关闭 CPU。 基本上，操作系统希望尽快找到能够完成的进程，这样它就可以继续喝茶并运行恶意软件。
The next thread to unblock on it's
sem_wait()will be whatever thread the OS decides is the next one to context switch into. Nobody makes any guarantee of ordering; it depends on your OS's scheduling strategy. It might be the thread that has been off the CPU for the longest, or the one that has been assigned the highest "priority", or the one that has historically had certain resource-usage statistics, or whatever.Most likely, your current thread (the one that called
sem_post()) will continue running for a while, until it either starts waiting for user input, blocks on another semaphore, or runs out of its os-allotted time slice. Then, the OS will switch in some totally unrelated process to run for a fraction of a second (probably Firefox or something), then go off and handle some network traffic, get itself a cup of tea, and, finally, when it gets around to it, pick whichever of your other threads it feels like, based on something like whether it feels based on past history that the particular thread is more CPU or I/O-bound.In many OSes, priority is given to I/O-bound processes that haven't been around for very long. The theory is that new processes might be short-lived (if it's been around for five hours already, odds are it won't be finishing up in the next 1ms) so we might as well get them over with. I/O-bound processes are likely to continue to be I/O-bound, which means that chances are they are going to switch off the CPU shortly while waiting for other resources. Basically, the OS wants to find the process that it's going to be able to be done with ASAP, so it can get back to sipping its tea and running your malware.
信号量有两个操作：
P()获取信号量（你似乎称之为sem_wait）V()释放信号量（你似乎称之为sem_post）信号量也有一个整数与它们相关联，这是允许在不阻塞的情况下通过 P() 的并发线程数。 对 P() 的其他调用将阻塞，直到调用 V() 来释放位置。
这是信号量的经典定义。
编辑：信号量不保证任何顺序。 他们不必实际使用队列或其他 FIFO 结构。 当一次只允许一个线程时，当它调用 V() 时，另一个（可能是随机的）线程将从其 P() 调用中返回并继续。
Semaphores have two operations:
P()To acquire the semaphore (you seem to call thissem_wait)V()To release the semaphore (you seem to call thissem_post)Semaphores also have an integer associated to them, which is the number of concurrent threads allowed to pass P() without blocking. Other calls to P() will block until V() is called to free up spots.
That is the classic definition of a semaphore.
Edit: Semaphores do not make any guarantee of order. They don't have to actually use a queue or other FIFO structure. When only one thread is allowed at a time, when it calls V(), another (possibly random) thread will then return from its P() call and continue.
根据 IEEE 标准，POSIX 信号量的行为：
According to the IEEE standards, the behavior of POSIX semaphores: