2 "Title": "The Go Memory Model",
3 "Subtitle": "Version of March 6, 2012",
19 The Go memory model specifies the conditions under which
20 reads of a variable in one goroutine can be guaranteed to
21 observe values produced by writes to the same variable in a different goroutine.
24 <h2>Happens Before</h2>
27 Within a single goroutine, reads and writes must behave
28 as if they executed in the order specified by the program.
29 That is, compilers and processors may reorder the reads and writes
30 executed within a single goroutine only when the reordering
31 does not change the behavior within that goroutine
32 as defined by the language specification.
33 Because of this reordering, the execution order observed
34 by one goroutine may differ from the order perceived
35 by another. For example, if one goroutine
36 executes <code>a = 1; b = 2;</code>, another might observe
37 the updated value of <code>b</code> before the updated value of <code>a</code>.
41 To specify the requirements of reads and writes, we define
42 <i>happens before</i>, a partial order on the execution
43 of memory operations in a Go program. If event <span class="event">e<sub>1</sub></span> happens
44 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>.
45 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
46 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.
50 Within a single goroutine, the happens-before order is the
51 order expressed by the program.
55 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>
56 if both of the following hold:
60 <li><span class="event">r</span> does not happen before <span class="event">w</span>.</li>
61 <li>There is no other write <span class="event">w'</span> to <code>v</code> that happens
62 after <span class="event">w</span> but before <span class="event">r</span>.</li>
66 To guarantee that a read <span class="event">r</span> of a variable <code>v</code> observes a
67 particular write <span class="event">w</span> to <code>v</code>, ensure that <span class="event">w</span> is the only
68 write <span class="event">r</span> is allowed to observe.
69 That is, <span class="event">r</span> is <i>guaranteed</i> to observe <span class="event">w</span> if both of the following hold:
73 <li><span class="event">w</span> happens before <span class="event">r</span>.</li>
74 <li>Any other write to the shared variable <code>v</code>
75 either happens before <span class="event">w</span> or after <span class="event">r</span>.</li>
79 This pair of conditions is stronger than the first pair;
80 it requires that there are no other writes happening
81 concurrently with <span class="event">w</span> or <span class="event">r</span>.
85 Within a single goroutine,
86 there is no concurrency, so the two definitions are equivalent:
87 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>.
88 When multiple goroutines access a shared variable <code>v</code>,
89 they must use synchronization events to establish
90 happens-before conditions that ensure reads observe the
95 The initialization of variable <code>v</code> with the zero value
96 for <code>v</code>'s type behaves as a write in the memory model.
100 Reads and writes of values larger than a single machine word
101 behave as multiple machine-word-sized operations in an
105 <h2>Synchronization</h2>
107 <h3>Initialization</h3>
110 Program initialization runs in a single goroutine,
111 but that goroutine may create other goroutines,
112 which run concurrently.
116 If a package <code>p</code> imports package <code>q</code>, the completion of
117 <code>q</code>'s <code>init</code> functions happens before the start of any of <code>p</code>'s.
121 The start of the function <code>main.main</code> happens after
122 all <code>init</code> functions have finished.
125 <h3>Goroutine creation</h3>
128 The <code>go</code> statement that starts a new goroutine
129 happens before the goroutine's execution begins.
133 For example, in this program:
150 calling <code>hello</code> will print <code>"hello, world"</code>
151 at some point in the future (perhaps after <code>hello</code> has returned).
154 <h3>Goroutine destruction</h3>
157 The exit of a goroutine is not guaranteed to happen before
158 any event in the program. For example, in this program:
165 go func() { a = "hello" }()
171 the assignment to <code>a</code> is not followed by
172 any synchronization event, so it is not guaranteed to be
173 observed by any other goroutine.
174 In fact, an aggressive compiler might delete the entire <code>go</code> statement.
178 If the effects of a goroutine must be observed by another goroutine,
179 use a synchronization mechanism such as a lock or channel
180 communication to establish a relative ordering.
183 <h3>Channel communication</h3>
186 Channel communication is the main method of synchronization
187 between goroutines. Each send on a particular channel
188 is matched to a corresponding receive from that channel,
189 usually in a different goroutine.
193 A send on a channel happens before the corresponding
194 receive from that channel completes.
202 var c = make(chan int, 10)
218 is guaranteed to print <code>"hello, world"</code>. The write to <code>a</code>
219 happens before the send on <code>c</code>, which happens before
220 the corresponding receive on <code>c</code> completes, which happens before
221 the <code>print</code>.
225 The closing of a channel happens before a receive that returns a zero value
226 because the channel is closed.
230 In the previous example, replacing
231 <code>c <- 0</code> with <code>close(c)</code>
232 yields a program with the same guaranteed behavior.
236 A receive from an unbuffered channel happens before
237 the send on that channel completes.
241 This program (as above, but with the send and receive statements swapped and
242 using an unbuffered channel):
246 var c = make(chan int)
264 is also guaranteed to print <code>"hello, world"</code>. The write to <code>a</code>
265 happens before the receive on <code>c</code>, which happens before
266 the corresponding send on <code>c</code> completes, which happens
267 before the <code>print</code>.
271 If the channel were buffered (e.g., <code>c = make(chan int, 1)</code>)
272 then the program would not be guaranteed to print
273 <code>"hello, world"</code>. (It might print the empty string,
274 crash, or do something else.)
280 The <code>sync</code> package implements two lock data types,
281 <code>sync.Mutex</code> and <code>sync.RWMutex</code>.
285 For any <code>sync.Mutex</code> or <code>sync.RWMutex</code> variable <code>l</code> and <i>n</i> < <i>m</i>,
286 call <i>n</i> of <code>l.Unlock()</code> happens before call <i>m</i> of <code>l.Lock()</code> returns.
311 is guaranteed to print <code>"hello, world"</code>.
312 The first call to <code>l.Unlock()</code> (in <code>f</code>) happens
313 before the second call to <code>l.Lock()</code> (in <code>main</code>) returns,
314 which happens before the <code>print</code>.
318 For any call to <code>l.RLock</code> on a <code>sync.RWMutex</code> variable <code>l</code>,
319 there is an <i>n</i> such that the <code>l.RLock</code> happens (returns) after call <i>n</i> to
320 <code>l.Unlock</code> and the matching <code>l.RUnlock</code> happens
321 before call <i>n</i>+1 to <code>l.Lock</code>.
327 The <code>sync</code> package provides a safe mechanism for
328 initialization in the presence of multiple goroutines
329 through the use of the <code>Once</code> type.
330 Multiple threads can execute <code>once.Do(f)</code> for a particular <code>f</code>,
331 but only one will run <code>f()</code>, and the other calls block
332 until <code>f()</code> has returned.
336 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.
363 calling <code>twoprint</code> causes <code>"hello, world"</code> to be printed twice.
364 The first call to <code>doprint</code> runs <code>setup</code> once.
367 <h2>Incorrect synchronization</h2>
370 Note that a read <span class="event">r</span> may observe the value written by a write <span class="event">w</span>
371 that happens concurrently with <span class="event">r</span>.
372 Even if this occurs, it does not imply that reads happening after <span class="event">r</span>
373 will observe writes that happened before <span class="event">w</span>.
400 it can happen that <code>g</code> prints <code>2</code> and then <code>0</code>.
404 This fact invalidates a few common idioms.
408 Double-checked locking is an attempt to avoid the overhead of synchronization.
409 For example, the <code>twoprint</code> program might be
410 incorrectly written as:
436 but there is no guarantee that, in <code>doprint</code>, observing the write to <code>done</code>
437 implies observing the write to <code>a</code>. This
438 version can (incorrectly) print an empty string
439 instead of <code>"hello, world"</code>.
443 Another incorrect idiom is busy waiting for a value, as in:
464 As before, there is no guarantee that, in <code>main</code>,
465 observing the write to <code>done</code>
466 implies observing the write to <code>a</code>, so this program could
467 print an empty string too.
468 Worse, there is no guarantee that the write to <code>done</code> will ever
469 be observed by <code>main</code>, since there are no synchronization
470 events between the two threads. The loop in <code>main</code> is not
471 guaranteed to finish.
475 There are subtler variants on this theme, such as this program.
487 t.msg = "hello, world"
500 Even if <code>main</code> observes <code>g != nil</code> and exits its loop,
501 there is no guarantee that it will observe the initialized
502 value for <code>g.msg</code>.
506 In all these examples, the solution is the same:
507 use explicit synchronization.