code review 893041: Update doc/go_mem.html to remove semicolons.

doc/go_mem.html

 <!-- 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>
 
@@ skipping 108 matching lines @@
 <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;
+var a string
 
 func f() {
-        print(a);
+        print(a)
 }
 
 func hello() {
-        a = "hello, world";
-        go f();
+        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>
 
@@ skipping 11 matching lines @@
 
 <p>
 This program:
 </p>
 
 <pre>
 var c = make(chan int, 10)
 var a string
 
 func f() {
-        a = "hello, world";
-        c &lt;- 0;
+        a = "hello, world"
+        c &lt;- 0
 }
 
 func main() {
-        go f();
-        &lt;-c;
-        print(a);
+        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;
+        a = "hello, world"
+        &lt;-c
 }
 </pre>
 
 <pre>
 func main() {
-        go f();
-        c &lt;- 0;
-        print(a);
+        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>
 
@@ skipping 18 matching lines @@
 
 <p>
 This program:
 </p>
 
 <pre>
 var l sync.Mutex
 var a string
 
 func f() {
-        a = "hello, world";
-        l.Unlock();
+        a = "hello, world"
+        l.Unlock()
 }
 
 func main() {
-        l.Lock();
-        go f();
-        l.Lock();
-        print(a);
+        l.Lock()
+        go f()
+        l.Lock()
+        print(a)
 }
 </pre>
 
 <p>
 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>.
 </p>
 
@@ skipping 19 matching lines @@
 </p>
 
 <p>
 In this program:
 </p>
 
 <pre>
 var a string
 
 func setup() {
-        a = "hello, world";
+        a = "hello, world"
 }
 
 func doprint() {
-        once.Do(setup);
-        print(a);
+        once.Do(setup)
+        print(a)
 }
 
 func twoprint() {
-        go doprint();
-        go doprint();
+        go doprint()
+        go doprint()
 }
 </pre>
 
 <p>
 calling <code>twoprint</code> causes <code>"hello, world"</code> to be printed twice.
 The first call to <code>twoprint</code> runs <code>setup</code> once.
 </p>
 
 <h2>Incorrect synchronization</h2>
 
 <p>
 Note that a read <span class="event">r</span> may observe the value written by a write <span class="event">w</span>
 that happens concurrently with <span class="event">r</span>.
 Even if this occurs, it does not imply that reads happening after <span class="event">r</span>
 will observe writes that happened before <span class="event">w</span>.
 </p>
 
 <p>
 In this program:
 </p>
 
 <pre>
 var a, b int
 
 func f() {
-        a = 1;
-        b = 2;
+        a = 1
+        b = 2
 }
 
 func g() {
-        print(b);
-        print(a);
+        print(b)
+        print(a)
 }
 
 func main() {
-        go f();
-        g();
+        go f()
+        g()
 }
 </pre>
 
 <p>
 it can happen that <code>g</code> prints <code>2</code> and then <code>0</code>.
 </p>
 
 <p>
 This fact invalidates a few common idioms.
 </p>
 
 <p>
 Double-checked locking is an attempt to avoid the overhead of synchronization.
 For example, the <code>twoprint</code> program might be
 incorrectly written as:
 </p>
 
 <pre>
 var a string
 var done bool
 
 func setup() {
-        a = "hello, world";
-        done = true;
+        a = "hello, world"
+        done = true
 }
 
 func doprint() {
         if !done {
-                once.Do(setup);
+                once.Do(setup)
         }
-        print(a);
+        print(a)
 }
 
 func twoprint() {
-        go doprint();
-        go doprint();
+        go doprint()
+        go doprint()
 }
 </pre>
 
 <p>
 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>.
 </p>
 
 <p>
 Another incorrect idiom is busy waiting for a value, as in:
 </p>
 
 <pre>
 var a string
 var done bool
 
 func setup() {
-        a = "hello, world";
-        done = true;
+        a = "hello, world"
+        done = true
 }
 
 func main() {
-        go setup();
+        go setup()
         for !done {
         }
-        print(a);
+        print(a)
 }
 </pre>
 
 <p>
 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.
 </p>
 
 <p>
 There are subtler variants on this theme, such as this program.
 </p>
 
 <pre>
 type T struct {
-        msg string;
+        msg string
 }
 
 var g *T
 
 func setup() {
-        t := new(T);
-        t.msg = "hello, world";
-        g = t;
+        t := new(T)
+        t.msg = "hello, world"
+        g = t
 }
 
 func main() {
-        go setup();
+        go setup()
         for g == nil {
         }
-        print(g.msg);
+        print(g.msg)
 }
 </pre>
 
 <p>
 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>.
 </p>
 
 <p>
 In all these examples, the solution is the same:
 use explicit synchronization.
 </p>