信号量术语

发布于 2025-01-02 13:22:25 字数 224 浏览 4 评论 0原文

通常谈论的信号量......它们涉及忙等待吗?我对术语感到困惑。请告诉我我得出的结论中哪些是正确的。

a)自旋锁涉及忙等待,因此为了避免这种情况,我们有信号量。
b) 信号量是自旋锁的一种,但是我们可以拥有信号量而无需忙于等待
c)pthread_condition变量与信号量做同样的事情?如果是这样,它们是否相当于 semaphore.h 库中的信号量。如果两者代表相同的功能,我很困惑。

The usually talked of semaphores... Do they involve busy waiting? I am confused with the terminology. Please tell me which among the connclusions i was able to draw are true.

a)Spinlocks involve busy waiting, so to avoid that,we have semaphores.
b)Semaphores are a kind of spinlocks, but we can have semaphores without busy waiting
c)pthread_condition variables do the same thing as semaphores? If so,are they equivalent to semaphores from semaphore.h library. I am confused if both represent the same functionality.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

椵侞 2025-01-09 13:22:25

抽象地说,信号量是一个带有许多与其关联的许可的锁。信号量支持两种操作:

  1. 向上(增加许可数量)和
  2. 向下(尝试减少许可数量)。如果没有足够的许可证可用,则此操作将等待,直到有足够的可用许可证。

实现信号量的方法有很多种。但通常情况下,信号量不会被实现为自旋锁,并且实际上让操作系统阻塞线程并使其休眠,直到请求的许可可用为止。也就是说,信号量的完全合法的实现可以使其处于忙等待状态;我只是不知道有任何实现可以做到这一点。

条件变量代表不同的概念。通常,信号量旨在管理仅存在这么多副本的资源。每个需要该资源的线程都会等待,直到保护对该资源的访问的信号量变得可用,并且每个使用该资源的线程都拥有一个许可证。条件变量通常用于允许线程等待某些事件的发生。它们通常支持操作

  1. 等待,它会阻塞线程直到收到信号,
  2. 通知,它告诉一个正在等待条件变量的线程它可以继续,以及
  3. Notify-all,它告诉所有等待条件变量的线程它们可以继续。

条件变量和信号量(通常)可以互换使用,并对锁使用的设计进行适当的更改。但是,有时信号量更容易使用,有时条件变量更容易使用,因此我们可以使用这两种原语。通常,由于您使用的特定库或语言,您会选择使用其中一种。例如,Java 对象具有对监视器(与锁配对的条件变量)的内置支持,因此在 Java 中使用条件变量通常很有用,尽管 Java 信号量确实存在。如果您在 Windows 中编程,那么信号量是首选的同步方法,尽管条件变量确实存在。

希望这有帮助!

Abstractly, a semaphore is a lock with a number of permits associated with it. Semaphores support two operations:

  1. Up, which increases the number of permits, and
  2. Down, which attempts to decrease the number of permits. If insufficient permits are available, then this operation waits until enough are available.

There are many ways to implement semaphores. Typically, though, semaphores are not implemented as spinlocks, and actually have the OS block the thread and have it sleep until the requested permit becomes available. That said, a perfectly legal implementation of a semaphore could have it busy-wait; I'm just not aware of any implementations that do this.

Condition variables represent a different concept. Typically, semaphores are designed to manage a resource where only so many copies exist. Each thread that wants the resource waits until the semaphore guarding access to it becomes available, and each thread using the resource owns one permit. Condition variables are typically used to allow threads to wait for certain events to occur. They usually support the operations

  1. Wait, which blocks the thread until it is signaled,
  2. Notify, which tells one thread waiting on the condition variable that it can proceed, and
  3. Notify-all, which tells all threads waiting on the condition variable that they can proceed.

Condition variables and semaphores can (usually) be used interchangeably, with a suitable change to the design of the lock usage. However, sometimes semaphores are easier to work with, and sometimes condition variables are easier to work with, so we have both primitives available. Commonly, you'll choose to use one over the other because of the particular library or language you're using. For example, Java objects have built-in support for monitors (condition variables paired with a lock), so it's often useful to use condition variables in Java, though Java semaphores do exist. If you're programming in Windows, then semaphores are the preferred method of synchronization, though condition variables do exist.

Hope this helps!

眼眸印温柔 2025-01-09 13:22:25

自旋锁使用忙等待,因此得名自旋——线程自旋不执行任何操作。

它的作用是“我可以进去吗?我可以进去吗?我可以进去...等等”直到锁允许它进入临界区(CS)

信号量:通常用信号/通知和队列来实现,所以当一个线程踩在信号量上,如果临界区中有另一个线程,它就会进入睡眠状态并进入队列。如果CS中没有其他线程,则当前线程进入其中。当另一个线程在 CS 中时踩到信号量的所有其他线程都会进入队列。当第一个线程退出 CS 时,它会再次踩到信号量。信号量现在获取其队列中的第一个线程并唤醒它,这又使该线程进入 CS。

使用signal/wait实现的信号量,线程说我可以进去吗?如果没有,它会说当我可以的时候叫醒我。如果是,则进入。

编辑:信号量与条件 条件

上的等待和信号操作与计数信号量上的 P 和 V 操作非常相似。 wait 语句可以阻止线程的执行,而 signal 语句可以导致另一个线程的恢复。然而,它们之间也存在差异。 P 操作不一定会阻塞线程,因为信号量计数器可能大于零。然而,wait 语句总是阻塞线程。信号语句可以在某个条件下准备好(解除阻塞)阻塞线程,就像 V 操作在信号量上准备好阻塞线程一样。不同之处在于 V 操作总是递增信号量计数器;从而影响后续的P操作。空条件下的信号语句不会影响后续的等待语句,因此会丢失。另一个区别是,如果执行了足够多的 V 操作,则阻塞在信号量上的多个线程可以立即恢复执行。在互斥体类型的情况下,多个信号语句确实可以解除多个线程的阻塞,但由于互斥体类型的互斥特性,只有其中一个线程能够执行。

spinlocks use busy waiting, hence the name spin - thread spins doing nothing.

What it does is "can I go in? can I go in? can I go in... etc" until the lock allows it in the critical section (CS)

semaphores: usually implemented with a signal/notify and a queue so when a thread steps on a semaphore it goes to sleep and into the queue if there is another thread in the critical section. If there is no other thread in the CS, the current thread enters it. All other threads who step on the semaphore while another thread is in the CS go in the queue. When the first thread exits the CS, it steps on the semaphore again. The semaphore now takes the first thread in its queue and awakens it, which in turns makes the thread enter the CS.

With a semaphore implemented with signal/wait, the thread says can I go in? If no, the it says wake me up when I can. If yes, it goes in.

EDIT: Semaphores vs Conditions

The wait and signal operations on conditions are very similar to the P and V operations on counting semaphores. The wait statement can block a thread’s execution while a signal statement can cause resumption of another thread. There are, however, differences between them. The P operation does not necessarily block a thread, since the semaphore counter may be greater than zero. The wait statement, however, always blocks a thread. The signal statement can make ready (unblock) a blocked thread on a condition just as a V operation makes ready a blocked thread on a semaphore. The difference is that a V operation always increments the semaphore counter; thereby affecting a subsequent P operation. A signal statement on an empty condition does not affect a subsequent wait statement, and therefore, is lost. Another difference is that multiple threads blocked on a semaphore can resume execution without delay if enough V operations are performed. In the mutex-type case, multiple signal statements do unblock multiple threads, but only one of these threads is able to execute because of the mutual-exclusion property of the mutex type.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文