Question

I just observed and confirmed that Go closure captures external variables by reference. If the variable is captured into a Goroutine and if the Goroutine multiplexed into different thread,

  • is it safe to modify the value in the closure?
  • If it's not safe, why doesn't Go prevent this?
  • Or does it employ some safety mechanism? (such as lock)
Was it helpful?

Solution

Go does capture external variables by reference in closures as you've noticed.

Is it safe to modify the value in the closure?

It is a variable just like any other so the same rules apply as would in normal Go code. It is safe to modify it, but if you are modifying it concurrently then you need to supply your own locking or use an atomic type.

See The Go Memory model for the full details.

If it's not safe, why don't Go prevent this?

It is no different from accessing any other variable shared between go routines. You can do it safely and you can do it unsafely - Go gives you the freedom to shoot yourself in the foot if you want!

Go has an excellent race detector though which can find concurrent variable access problems.

Or does it employ some safety machinery? (such as lock)

No. Go never locks stuff for you - you need to use the primitives provided in the sync package or follow the Go philosophy of Do not communicate by sharing memory; instead, share memory by communicating, ie use channels to speak between go routines.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top