Gecko [ 167.86.127.34 ]

Name	Size	Permission
articles	[ DIR ]	drwxr-xr-x
codewalk	[ DIR ]	drwxr-xr-x
gopher	[ DIR ]	drwxr-xr-x
play	[ DIR ]	drwxr-xr-x
progs	[ DIR ]	drwxr-xr-x
asm.html	33.62 KB	-rw-r--r--
cmd.html	2.8 KB	-rw-r--r--
contrib.html	4.91 KB	-rw-r--r--
contribute.html	36.18 KB	-rw-r--r--
debugging_with_gdb.html	16.75 KB	-rw-r--r--
diagnostics.html	17.63 KB	-rw-r--r--
editors.html	1.37 KB	-rw-r--r--
effective_go.html	114 KB	-rw-r--r--
gccgo_contribute.html	4.22 KB	-rw-r--r--
gccgo_install.html	16.63 KB	-rw-r--r--
go-logo-black.png	8.64 KB	-rw-r--r--
go-logo-blue.png	9.14 KB	-rw-r--r--
go-logo-white.png	20.97 KB	-rw-r--r--
go1.1.html	39.46 KB	-rw-r--r--
go1.10.html	57.88 KB	-rw-r--r--
go1.11.html	35.48 KB	-rw-r--r--
go1.12.html	36.98 KB	-rw-r--r--
go1.13.html	44.99 KB	-rw-r--r--
go1.14.html	34.85 KB	-rw-r--r--
go1.2.html	34.18 KB	-rw-r--r--
go1.3.html	22.56 KB	-rw-r--r--
go1.4.html	32.75 KB	-rw-r--r--
go1.5.html	46.68 KB	-rw-r--r--
go1.6.html	36.72 KB	-rw-r--r--
go1.7.html	42.68 KB	-rw-r--r--
go1.8.html	57.64 KB	-rw-r--r--
go1.9.html	36.67 KB	-rw-r--r--
go1.html	69.79 KB	-rw-r--r--
go1compat.html	7.05 KB	-rw-r--r--
go_faq.html	87.98 KB	-rw-r--r--
go_mem.html	13.26 KB	-rw-r--r--
go_spec.html	207.92 KB	-rw-r--r--
help.html	3.05 KB	-rw-r--r--
ie.css	34 B	-rw-r--r--
install-source.html	22.66 KB	-rw-r--r--
install.html	9.1 KB	-rw-r--r--
share.png	2.92 KB	-rw-r--r--
tos.html	360 B	-rw-r--r--

Code Editor : go_mem.html

<h2>Introduction</h2>

The Go memory model specifies the conditions under which
reads of a variable in one goroutine can be guaranteed to
observe values produced by writes to the same variable in a different goroutine.

<h2>Advice</h2>

Programs that modify data being simultaneously accessed by multiple goroutines
must serialize such access.

To serialize access, protect the data with channel operations or other synchronization primitives
such as those in the <a href="/pkg/sync/"><code>sync</code></a>
and <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> packages.

If you must read the rest of this document to understand the behavior of your program,
you are being too clever.

Don't be clever.

<h2>Happens Before</h2>

Within a single goroutine, reads and writes must behave
as if they executed in the order specified by the program.
That is, compilers and processors may reorder the reads and writes
executed within a single goroutine only when the reordering
does not change the behavior within that goroutine
as defined by the language specification.
Because of this reordering, the execution order observed
by one goroutine may differ from the order perceived
by another. For example, if one goroutine
executes <code>a = 1; b = 2;</code>, another might observe
the updated value of <code>b</code> before the updated value of <code>a</code>.

To specify the requirements of reads and writes, we define
happens before, a partial order on the execution
of memory operations in a Go program. If event e1 happens
before event e2, then we say that e2 happens after e1.
Also, if e1 does not happen before e2 and does not happen
after e2, then we say that e1 and e2 happen concurrently.

Within a single goroutine, the happens-before order is the
order expressed by the program.

A read r of a variable <code>v</code> is allowed to observe a write w to <code>v</code>
if both of the following hold:

<ol>
<li>r does not happen before w.</li>
<li>There is no other write w' to <code>v</code> that happens
 after w but before r.</li>
</ol>

To guarantee that a read r of a variable <code>v</code> observes a
particular write w to <code>v</code>, ensure that w is the only
write r is allowed to observe.
That is, r is guaranteed to observe w if both of the following hold:

<ol>
<li>w happens before r.</li>
<li>Any other write to the shared variable <code>v</code>
either happens before w or after r.</li>
</ol>

This pair of conditions is stronger than the first pair;
it requires that there are no other writes happening
concurrently with w or r.

Within a single goroutine,
there is no concurrency, so the two definitions are equivalent:
a read r observes the value written by the most recent write w to <code>v</code>.
When multiple goroutines access a shared variable <code>v</code>,
they must use synchronization events to establish
happens-before conditions that ensure reads observe the
desired writes.

The initialization of variable <code>v</code> with the zero value
for <code>v</code>'s type behaves as a write in the memory model.

Reads and writes of values larger than a single machine word
behave as multiple machine-word-sized operations in an
unspecified order.

<h2>Synchronization</h2>

<h3>Initialization</h3>

Program initialization runs in a single goroutine,
but that goroutine may create other goroutines,
which run concurrently.

If a package <code>p</code> imports package <code>q</code>, the completion of
<code>q</code>'s <code>init</code> functions happens before the start of any of <code>p</code>'s.

The start of the function <code>main.main</code> happens after
all <code>init</code> functions have finished.

<h3>Goroutine creation</h3>

The <code>go</code> statement that starts a new goroutine
happens before the goroutine's execution begins.

For example, in this program:

<pre>
var a string

func f() {
	print(a)
}

func hello() {
	a = "hello, world"
	go f()
}
</pre>

calling <code>hello</code> will print <code>"hello, world"</code>
at some point in the future (perhaps after <code>hello</code> has returned).

<h3>Goroutine destruction</h3>

The exit of a goroutine is not guaranteed to happen before
any event in the program. For example, in this program:

<pre>
var a string

func hello() {
	go func() { a = "hello" }()
	print(a)
}
</pre>

the assignment to <code>a</code> is not followed by
any synchronization event, so it is not guaranteed to be
observed by any other goroutine.
In fact, an aggressive compiler might delete the entire <code>go</code> statement.

If the effects of a goroutine must be observed by another goroutine,
use a synchronization mechanism such as a lock or channel
communication to establish a relative ordering.

<h3>Channel communication</h3>

Channel communication is the main method of synchronization
between goroutines. Each send on a particular channel
is matched to a corresponding receive from that channel,
usually in a different goroutine.

A send on a channel happens before the corresponding
receive from that channel completes.

This program:

<pre>
var c = make(chan int, 10)
var a string

func f() {
	a = "hello, world"
	c &lt;- 0
}

func main() {
	go f()
	&lt;-c
	print(a)
}
</pre>

is guaranteed to print <code>"hello, world"</code>. The write to <code>a</code>
happens before the send on <code>c</code>, which happens before
the corresponding receive on <code>c</code> completes, which happens before
the <code>print</code>.

The closing of a channel happens before a receive that returns a zero value
because the channel is closed.

In the previous example, replacing
<code>c &lt;- 0</code> with <code>close(c)</code>
yields a program with the same guaranteed behavior.

A receive from an unbuffered channel happens before
the send on that channel completes.

This program (as above, but with the send and receive statements swapped and
using an unbuffered channel):

<pre>
var c = make(chan int)
var a string

func f() {
	a = "hello, world"
	&lt;-c
}
</pre>

<pre>
func main() {
	go f()
	c &lt;- 0
	print(a)
}
</pre>

is also guaranteed to print <code>"hello, world"</code>. The write to <code>a</code>
happens before the receive on <code>c</code>, which happens before
the corresponding send on <code>c</code> completes, which happens
before the <code>print</code>.

If the channel were buffered (e.g., <code>c = make(chan int, 1)</code>)
then the program would not be guaranteed to print
<code>"hello, world"</code>. (It might print the empty string,
crash, or do something else.)

The kth receive on a channel with capacity C happens before the k+Cth send from that channel completes.

This rule generalizes the previous rule to buffered channels.
It allows a counting semaphore to be modeled by a buffered channel:
the number of items in the channel corresponds to the number of active uses,
the capacity of the channel corresponds to the maximum number of simultaneous uses,
sending an item acquires the semaphore, and receiving an item releases
the semaphore.
This is a common idiom for limiting concurrency.

This program starts a goroutine for every entry in the work list, but the
goroutines coordinate using the <code>limit</code> channel to ensure
that at most three are running work functions at a time.

<pre>
var limit = make(chan int, 3)

func main() {
	for _, w := range work {
		go func(w func()) {
			limit &lt;- 1
			w()
			&lt;-limit
		}(w)
	}
	select{}
}
</pre>

<h3>Locks</h3>

The <code>sync</code> package implements two lock data types,
<code>sync.Mutex</code> and <code>sync.RWMutex</code>.

For any <code>sync.Mutex</code> or <code>sync.RWMutex</code> variable <code>l</code> and n &lt; m,
call n of <code>l.Unlock()</code> happens before call m of <code>l.Lock()</code> returns.

This program:

<pre>
var l sync.Mutex
var a string

func f() {
	a = "hello, world"
	l.Unlock()
}

func main() {
	l.Lock()
	go f()
	l.Lock()
	print(a)
}
</pre>

is guaranteed to print <code>"hello, world"</code>.
The first call to <code>l.Unlock()</code> (in <code>f</code>) happens
before the second call to <code>l.Lock()</code> (in <code>main</code>) returns,
which happens before the <code>print</code>.

For any call to <code>l.RLock</code> on a <code>sync.RWMutex</code> variable <code>l</code>,
there is an n such that the <code>l.RLock</code> happens (returns) after call n to
<code>l.Unlock</code> and the matching <code>l.RUnlock</code> happens
before call n+1 to <code>l.Lock</code>.

The <code>sync</code> package provides a safe mechanism for
initialization in the presence of multiple goroutines
through the use of the <code>Once</code> type.
Multiple threads can execute <code>once.Do(f)</code> for a particular <code>f</code>,
but only one will run <code>f()</code>, and the other calls block
until <code>f()</code> has returned.

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.

In this program:

<pre>
var a string
var once sync.Once

func setup() {
	a = "hello, world"
}

func doprint() {
	once.Do(setup)
	print(a)
}

func twoprint() {
	go doprint()
	go doprint()
}
</pre>

calling <code>twoprint</code> will call <code>setup</code> exactly
once.
The <code>setup</code> function will complete before either call
of <code>print</code>.
The result will be that <code>"hello, world"</code> will be printed
twice.

<h2>Incorrect synchronization</h2>

Note that a read r may observe the value written by a write w
that happens concurrently with r.
Even if this occurs, it does not imply that reads happening after r
will observe writes that happened before w.

In this program:

<pre>
var a, b int

func f() {
	a = 1
	b = 2
}

func g() {
	print(b)
	print(a)
}

func main() {
	go f()
	g()
}
</pre>

it can happen that <code>g</code> prints <code>2</code> and then <code>0</code>.

This fact invalidates a few common idioms.

Double-checked locking is an attempt to avoid the overhead of synchronization.
For example, the <code>twoprint</code> program might be
incorrectly written as:

<pre>
var a string
var done bool

func setup() {
	a = "hello, world"
	done = true
}

func doprint() {
	if !done {
		once.Do(setup)
	}
	print(a)
}

func twoprint() {
	go doprint()
	go doprint()
}
</pre>

but there is no guarantee that, in <code>doprint</code>, observing the write to <code>done</code>
implies observing the write to <code>a</code>. This
version can (incorrectly) print an empty string
instead of <code>"hello, world"</code>.

Another incorrect idiom is busy waiting for a value, as in:

<pre>
var a string
var done bool

func setup() {
	a = "hello, world"
	done = true
}

func main() {
	go setup()
	for !done {
	}
	print(a)
}
</pre>

As before, there is no guarantee that, in <code>main</code>,
observing the write to <code>done</code>
implies observing the write to <code>a</code>, so this program could
print an empty string too.
Worse, there is no guarantee that the write to <code>done</code> will ever
be observed by <code>main</code>, since there are no synchronization
events between the two threads. The loop in <code>main</code> is not
guaranteed to finish.

There are subtler variants on this theme, such as this program.

<pre>
type T struct {
	msg string
}

var g *T

func setup() {
	t := new(T)
	t.msg = "hello, world"
	g = t
}

func main() {
	go setup()
	for g == nil {
	}
	print(g.msg)
}
</pre>

Even if <code>main</code> observes <code>g != nil</code> and exits its loop,
there is no guarantee that it will observe the initialized
value for <code>g.msg</code>.

In all these examples, the solution is the same:
use explicit synchronization.

${this.title}

Code Editor : go_mem.html