<commit_before><!-- The Go Memory Model -->

<h2>Introduction</h2>

<p>
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.
</p>

<h2>Happens Before</h2>

<p>
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>.
</p>

<p>
To specify the requirements of reads and writes, we define
<i>happens before</i>, a partial order on the execution
of memory operations in a Go program.  If event <span class="event">e<sub>1</sub></span> happens
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>.
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
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.
</p>

<p>
Within a single goroutine, the happens before order is the
order expressed by the program.
</p>

<p>
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>
if both of the following hold:
</p>

<ol>
<li><span class="event">w</span> happens before <span class="event">r</span>.</li>
<li>There is no other write <span class="event">w'</span> to <code>v</code> that happens
    after <span class="event">w</span> but before <span class="event">r</span>.</li>
</ol>

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

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

<p>
This pair of conditions is stronger than the first pair;
it requires that there are no other writes happening
concurrently with <span class="event">w</span> or <span class="event">r</span>.
</p>

<p>
Within a single goroutine,
there is no concurrency, so the two definitions are equivalent:
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>.
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.
</p>

<p>
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.
</p>

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

<h2>Synchronization</h2>

<h3>Initialization</h3>

<p>
Program initialization runs in a single goroutine and
new goroutines created during initialization do not
start running until initialization ends.
</p>

<p class="rule">
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.
</p>

<p class="rule">
The start of the function <code>main.main</code> happens after
all <code>init</code> functions have finished.
</p>

<p class="rule">
The execution of any goroutines created during <code>init</code>
functions happens after all <code>init</code> functions have finished.
</p>

<h3>Goroutine creation</h3>

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

<p>
For example, in this program:
</p>

<pre>
var a string;

func f() {
	print(a);
}

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

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

<h3>Channel communication</h3>

<p>
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.
</p>

<p class="rule">
A send on a channel happens before the corresponding
receive from that channel completes.
</p>

<p>
This program:
</p>

<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>

<p>
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>.
</p>

<p class="rule">
A receive from an unbuffered channel happens before
the send on that channel completes.
</p>

<p>
This program:
</p>

<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>

<p>
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>.
</p>

<p>
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;
it cannot print <code>"hello, sailor"</code>, nor can it crash.)
</p>

<h3>Locks</h3>

<p>
The <code>sync</code> package implements two lock data types,
<code>sync.Mutex</code> and <code>sync.RWMutex</code>.
</p><commit_msg>go_mem: clarified unbuffered channel sync example<commit_after><!-- The Go Memory Model -->

<h2>Introduction</h2>

<p>
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.
</p>

<h2>Happens Before</h2>

<p>
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>.
</p>

<p>
To specify the requirements of reads and writes, we define
<i>happens before</i>, a partial order on the execution
of memory operations in a Go program.  If event <span class="event">e<sub>1</sub></span> happens
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>.
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
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.
</p>

<p>
Within a single goroutine, the happens before order is the
order expressed by the program.
</p>

<p>
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>
if both of the following hold:
</p>

<ol>
<li><span class="event">w</span> happens before <span class="event">r</span>.</li>
<li>There is no other write <span class="event">w'</span> to <code>v</code> that happens
    after <span class="event">w</span> but before <span class="event">r</span>.</li>
</ol>

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

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

<p>
This pair of conditions is stronger than the first pair;
it requires that there are no other writes happening
concurrently with <span class="event">w</span> or <span class="event">r</span>.
</p>

<p>
Within a single goroutine,
there is no concurrency, so the two definitions are equivalent:
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>.
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.
</p>

<p>
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.
</p>

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

<h2>Synchronization</h2>

<h3>Initialization</h3>

<p>
Program initialization runs in a single goroutine and
new goroutines created during initialization do not
start running until initialization ends.
</p>

<p class="rule">
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.
</p>

<p class="rule">
The start of the function <code>main.main</code> happens after
all <code>init</code> functions have finished.
</p>

<p class="rule">
The execution of any goroutines created during <code>init</code>
functions happens after all <code>init</code> functions have finished.
</p>

<h3>Goroutine creation</h3>

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

<p>
For example, in this program:
</p>

<pre>
var a string;

func f() {
	print(a);
}

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

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

<h3>Channel communication</h3>

<p>
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.
</p>

<p class="rule">
A send on a channel happens before the corresponding
receive from that channel completes.
</p>

<p>
This program:
</p>

<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>

<p>
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>.
</p>

<p class="rule">
A receive from an unbuffered channel happens before
the send on that channel completes.
</p>

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

<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>

<p>
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>.
</p>

<p>
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;
it cannot print <code>"goodbye, universe"</code>, nor can it crash.)
</p>

<h3>Locks</h3>

<p>
The <code>sync</code> package implements two lock data types,
<code>sync.Mutex</code> and <code>sync.RWMutex</code>.
</p>
{'fraction_non_alphanumeric': 0.14078859434172422, 'fraction_numerical': 0.0044553352639786145, 'mean_word_length': 4.848024316109423, 'pattern_counts': {'":': 0, '<': 513, '<?xml version=': 0, '>': 513, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6047133', 'n_tokens_mistral': 4404, 'n_tokens_neox': 4303, 'n_words': 1771}