Go Cond: Difference between revisions
Tags: Manual revert Reverted |
Tag: Manual revert |
||
| Line 2: | Line 2: | ||
* [[Go_Package_sync#Cond|The <tt>sync</tt> Package]] | * [[Go_Package_sync#Cond|The <tt>sync</tt> Package]] | ||
=Overview= | =Overview= | ||
<code>Cond</code> implements a '''condition variable''', a rendezvous point for goroutines waiting for or announcing the occurrence of an event. In this definition, an "event" is an arbitrary signal between two or more goroutines that carries no information other than the fact that it has occurred. | <code>Cond</code> implements a '''condition variable''', a rendezvous point for goroutines waiting for or announcing the occurrence of an event. In this definition, an "event" is an arbitrary signal between two or more goroutines that carries no information other than the fact that it has occurred. <code>Cond</code> offers a way for a goroutine to "efficiently sleep" (be suspended) until it is signaled to wake up and check of a condition. | ||
Each <code>Cond</code> has an associated <code>Locker</code> <code>L</code>, commonly a <code>*Mutex</code> or <code>*RWMutex</code>, which must be held when changing the condition and when calling the <code>Wait</code> method. A <code>Cond</code> must not be copied after first use. | Each <code>Cond</code> has an associated <code>Locker</code> <code>L</code>, commonly a <code>*Mutex</code> or <code>*RWMutex</code>, which must be held when changing the condition and when calling the <code>Wait</code> method. A <code>Cond</code> must not be copied after first use. | ||
In the terminology of the Go memory model, <code>Cond</code> arranges that a call to <code>Broadcast()</code> or <code>Signal()</code> "synchronizes before" any <code>Wait</code> call that it unblocks. For many simple use cases, users will be better off using channels than a <code>Cond</code> (<code>Broadcast()</code> corresponds to closing a channel, and <code>Signal</code> corresponds to sending on a channel). | In the terminology of the Go memory model, <code>Cond</code> arranges that a call to <code>Broadcast()</code> or <code>Signal()</code> "synchronizes before" any <code>Wait</code> call that it unblocks. For many simple use cases, users will be better off using channels than a <code>Cond</code> (<code>Broadcast()</code> corresponds to closing a channel, and <code>Signal</code> corresponds to sending on a channel). | ||
Revision as of 21:41, 20 January 2024
Internal
Overview
Cond implements a condition variable, a rendezvous point for goroutines waiting for or announcing the occurrence of an event. In this definition, an "event" is an arbitrary signal between two or more goroutines that carries no information other than the fact that it has occurred. Cond offers a way for a goroutine to "efficiently sleep" (be suspended) until it is signaled to wake up and check of a condition.
Each Cond has an associated Locker L, commonly a *Mutex or *RWMutex, which must be held when changing the condition and when calling the Wait method. A Cond must not be copied after first use.
In the terminology of the Go memory model, Cond arranges that a call to Broadcast() or Signal() "synchronizes before" any Wait call that it unblocks. For many simple use cases, users will be better off using channels than a Cond (Broadcast() corresponds to closing a channel, and Signal corresponds to sending on a channel).