1 <!-- The Go Memory Model -->
2 <!-- subtitle Version of June 10, 2011 -->
16 The Go memory model specifies the conditions under which
17 reads of a variable in one goroutine can be guaranteed to
18 observe values produced by writes to the same variable in a different goroutine.
21 <h2>Happens Before</h2>
24 Within a single goroutine, reads and writes must behave
25 as if they executed in the order specified by the program.
26 That is, compilers and processors may reorder the reads and writes
27 executed within a single goroutine only when the reordering
28 does not change the behavior within that goroutine
29 as defined by the language specification.
30 Because of this reordering, the execution order observed
31 by one goroutine may differ from the order perceived
32 by another. For example, if one goroutine
33 executes <code>a = 1; b = 2;</code>, another might observe
34 the updated value of <code>b</code> before the updated value of <code>a</code>.
38 To specify the requirements of reads and writes, we define
39 <i>happens before</i>, a partial order on the execution
40 of memory operations in a Go program. If event <span class="event">e<sub>1</sub></span> happens
41 before event <span class="event">e<sub>2</sub></span>, then we say that <span class="event">e<sub>2</sub></span> happens after <span class="event">e<sub>1</sub></span>.
42 Also, if <span class="event">e<sub>1</sub></span> does not happen before <span class="event">e<sub>2</sub></span> and does not happen
43 after <span class="event">e<sub>2</sub></span>, then we say that <span class="event">e<sub>1</sub></span> and <span class="event">e<sub>2</sub></span> happen concurrently.
47 Within a single goroutine, the happens-before order is the
48 order expressed by the program.
52 A read <span class="event">r</span> of a variable <code>v</code> is <i>allowed</i> to observe a write <span class="event">w</span> to <code>v</code>
53 if both of the following hold:
57 <li><span class="event">r</span> does not happen before <span class="event">w</span>.</li>
58 <li>There is no other write <span class="event">w'</span> to <code>v</code> that happens
59 after <span class="event">w</span> but before <span class="event">r</span>.</li>
63 To guarantee that a read <span class="event">r</span> of a variable <code>v</code> observes a
64 particular write <span class="event">w</span> to <code>v</code>, ensure that <span class="event">w</span> is the only
65 write <span class="event">r</span> is allowed to observe.
66 That is, <span class="event">r</span> is <i>guaranteed</i> to observe <span class="event">w</span> if both of the following hold:
70 <li><span class="event">w</span> happens before <span class="event">r</span>.</li>
71 <li>Any other write to the shared variable <code>v</code>
72 either happens before <span class="event">w</span> or after <span class="event">r</span>.</li>
76 This pair of conditions is stronger than the first pair;
77 it requires that there are no other writes happening
78 concurrently with <span class="event">w</span> or <span class="event">r</span>.
82 Within a single goroutine,
83 there is no concurrency, so the two definitions are equivalent:
84 a read <span class="event">r</span> observes the value written by the most recent write <span class="event">w</span> to <code>v</code>.
85 When multiple goroutines access a shared variable <code>v</code>,
86 they must use synchronization events to establish
87 happens-before conditions that ensure reads observe the
92 The initialization of variable <code>v</code> with the zero value
93 for <code>v</code>'s type behaves as a write in the memory model.
97 Reads and writes of values larger than a single machine word
98 behave as multiple machine-word-sized operations in an
102 <h2>Synchronization</h2>
104 <h3>Initialization</h3>
107 Program initialization runs in a single goroutine and
108 new goroutines created during initialization do not
109 start running until initialization ends.
113 If a package <code>p</code> imports package <code>q</code>, the completion of
114 <code>q</code>'s <code>init</code> functions happens before the start of any of <code>p</code>'s.
118 The start of the function <code>main.main</code> happens after
119 all <code>init</code> functions have finished.
123 The execution of any goroutines created during <code>init</code>
124 functions happens after all <code>init</code> functions have finished.
127 <h3>Goroutine creation</h3>
130 The <code>go</code> statement that starts a new goroutine
131 happens before the goroutine's execution begins.
135 For example, in this program:
152 calling <code>hello</code> will print <code>"hello, world"</code>
153 at some point in the future (perhaps after <code>hello</code> has returned).
156 <h3>Goroutine destruction</h3>
159 The exit of a goroutine is not guaranteed to happen before
160 any event in the program. For example, in this program:
167 go func() { a = "hello" }()
173 the assignment to <code>a</code> is not followed by
174 any synchronization event, so it is not guaranteed to be
175 observed by any other goroutine.
176 In fact, an aggressive compiler might delete the entire <code>go</code> statement.
180 If the effects of a goroutine must be observed by another goroutine,
181 use a synchronization mechanism such as a lock or channel
182 communication to establish a relative ordering.
185 <h3>Channel communication</h3>
188 Channel communication is the main method of synchronization
189 between goroutines. Each send on a particular channel
190 is matched to a corresponding receive from that channel,
191 usually in a different goroutine.
195 A send on a channel happens before the corresponding
196 receive from that channel completes.
204 var c = make(chan int, 10)
220 is guaranteed to print <code>"hello, world"</code>. The write to <code>a</code>
221 happens before the send on <code>c</code>, which happens before
222 the corresponding receive on <code>c</code> completes, which happens before
223 the <code>print</code>.
227 The closing of a channel happens before a receive that returns a zero value
228 because the channel is closed.
232 In the previous example, replacing
233 <code>c <- 0</code> with <code>close(c)</code>
234 yields a program with the same guaranteed behavior.
238 A receive from an unbuffered channel happens before
239 the send on that channel completes.
243 This program (as above, but with the send and receive statements swapped and
244 using an unbuffered channel):
248 var c = make(chan int)
266 is also guaranteed to print <code>"hello, world"</code>. The write to <code>a</code>
267 happens before the receive on <code>c</code>, which happens before
268 the corresponding send on <code>c</code> completes, which happens
269 before the <code>print</code>.
273 If the channel were buffered (e.g., <code>c = make(chan int, 1)</code>)
274 then the program would not be guaranteed to print
275 <code>"hello, world"</code>. (It might print the empty string;
276 it cannot print <code>"goodbye, universe"</code>, nor can it crash.)
282 The <code>sync</code> package implements two lock data types,
283 <code>sync.Mutex</code> and <code>sync.RWMutex</code>.
287 For any <code>sync.Mutex</code> or <code>sync.RWMutex</code> variable <code>l</code> and <i>n</i> < <i>m</i>,
288 the <i>n</i>'th call to <code>l.Unlock()</code> happens before the <i>m</i>'th call to <code>l.Lock()</code> returns.
313 is guaranteed to print <code>"hello, world"</code>.
314 The first call to <code>l.Unlock()</code> (in <code>f</code>) happens
315 before the second call to <code>l.Lock()</code> (in <code>main</code>) returns,
316 which happens before the <code>print</code>.
320 For any call to <code>l.RLock</code> on a <code>sync.RWMutex</code> variable <code>l</code>,
321 there is an <i>n</i> such that the <code>l.RLock</code> happens (returns) after the <i>n</i>'th call to
322 <code>l.Unlock</code> and the matching <code>l.RUnlock</code> happens
323 before the <i>n</i>+1'th call to <code>l.Lock</code>.
329 The <code>sync</code> package provides a safe mechanism for
330 initialization in the presence of multiple goroutines
331 through the use of the <code>Once</code> type.
332 Multiple threads can execute <code>once.Do(f)</code> for a particular <code>f</code>,
333 but only one will run <code>f()</code>, and the other calls block
334 until <code>f()</code> has returned.
338 A single call of <code>f()</code> from <code>once.Do(f)</code> happens (returns) before any call of <code>once.Do(f)</code> returns.
365 calling <code>twoprint</code> causes <code>"hello, world"</code> to be printed twice.
366 The first call to <code>twoprint</code> runs <code>setup</code> once.
369 <h2>Incorrect synchronization</h2>
372 Note that a read <span class="event">r</span> may observe the value written by a write <span class="event">w</span>
373 that happens concurrently with <span class="event">r</span>.
374 Even if this occurs, it does not imply that reads happening after <span class="event">r</span>
375 will observe writes that happened before <span class="event">w</span>.
402 it can happen that <code>g</code> prints <code>2</code> and then <code>0</code>.
406 This fact invalidates a few common idioms.
410 Double-checked locking is an attempt to avoid the overhead of synchronization.
411 For example, the <code>twoprint</code> program might be
412 incorrectly written as:
438 but there is no guarantee that, in <code>doprint</code>, observing the write to <code>done</code>
439 implies observing the write to <code>a</code>. This
440 version can (incorrectly) print an empty string
441 instead of <code>"hello, world"</code>.
445 Another incorrect idiom is busy waiting for a value, as in:
466 As before, there is no guarantee that, in <code>main</code>,
467 observing the write to <code>done</code>
468 implies observing the write to <code>a</code>, so this program could
469 print an empty string too.
470 Worse, there is no guarantee that the write to <code>done</code> will ever
471 be observed by <code>main</code>, since there are no synchronization
472 events between the two threads. The loop in <code>main</code> is not
473 guaranteed to finish.
477 There are subtler variants on this theme, such as this program.
489 t.msg = "hello, world"
502 Even if <code>main</code> observes <code>g != nil</code> and exits its loop,
503 there is no guarantee that it will observe the initialized
504 value for <code>g.msg</code>.
508 In all these examples, the solution is the same:
509 use explicit synchronization.