go/doc/go_mem.html at dev.cc · dominicbarnes/go

Repository navigation

History

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

558

559

560

561

562

563

564

565

566

<!--{

"Title": "The Go Memory Model",

"Subtitle": "Version of May 31, 2014",

"Path": "/ref/mem"

}-->

<style>

p.rule {

font-style: italic;

}

span.event {

font-style: italic;

}

</style>

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

}

func main() {

go f()

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

<-c

}

</pre>

<pre>

func main() {

go f()

c <- 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() {

limit <- 1

w()

<-limit

}()

}

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

}

</pre>

calling <code>twoprint</code> causes <code>"hello, world"</code> to be printed twice.

The first call to <code>doprint</code> runs <code>setup</code> once.

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

}

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

FilesExpand file tree

go_mem.html

Latest commit

History

go_mem.html

File metadata and controls