- Waiting for Goroutines with a WaitGroup
- Error Management with Error Groups
- Data Races
- Synchronizing Access with a Mutex
- Performing Tasks Only Once
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Synchronizing Access with a Mutex
When you run tests with the-raceflag, Go’s built-in race detector can help you find data races in your code. In Listing 13.30, for example, tests that pass normally fail when run with the race detector. The failure message lists the data race found and where the reads and writes occur in our code.
Listing 13.30 Detecting Race Conditions in Tests
$ go test -v -race === RUN Test_Mutex === PAUSE Test_Mutex === CONT Test_Mutex --- PASS: Test_Mutex (0.00s) PASS ================== WARNING: DATA RACE Read at 0x00c00019e3f0 by goroutine 9: runtime.mapdelete() /usr/local/go/src/runtime/map.go:695 +0x46c demo.Test_Mutex.func2() ./demo_test.go:46 +0x50 Previous write at 0x00c00019e3f0 by goroutine 8: runtime.mapaccess2_fast64() /usr/local/go/src/runtime/map_fast64.go:53 +0x1cc demo.Test_Mutex.func1() ./demo_test.go:32 +0x50 Goroutine 9 (running) created at: demo.Test_Mutex() ./demo_test.go:43 +0x188 testing.tRunner() /usr/local/go/src/testing/testing.go:1439 +0x18c testing.(*T).Run.func1() /usr/local/go/src/testing/testing.go:1486 +0x44 Goroutine 8 (finished) created at: demo.Test_Mutex() ./demo_test.go:28 +0x124 testing.tRunner() /usr/local/go/src/testing/testing.go:1439 +0x18c testing.(*T).Run.func1() /usr/local/go/src/testing/testing.go:1486 +0x44 ================== 0: true 2: true 4: true 7: true 9: true 1: true 3: true 5: true 6: true 8: true Found 1 data race(s) exit status 66 FAIL demo 0.862s
Go Version: go1.19
In the test in Listing 13.31, we have two different goroutines. The first is modifying a shared resource—in this case, a map. The second goroutine is ranging over the map and printing out the map’s values.
In order for us to be able to fix this race condition, we need to be able to synchronize access to the shared resource.
Listing 13.31 Two Goroutines Accessing a Shared Map
// launch a goroutine to // read data from the mapgo func() {// loop through the map // and print the keys/valuesfork,v:=rangedata{fmt.Printf("%d: %v\n",k,v) } }()// launch a goroutine to // put data in the mapgo func() {fori:=0;i<10;i++ {// loop putting data in the mapdata[i] =true}// cancel the contextcancel() }()
Locker
To synchronize access to the shared resource, we need to be able tolockaccess to the resource. By locking a shared resource, we can ensure that only one goroutine at a time can access the resource and that the resource is not modified by another goroutine while it is locked.
Thesync.Locker16interface, Listing 13.32, defines the methods that a type must implement to be able to lock and unlock a shared resource.
Listing 13.32 Thesync.LockerInterface
$ go doc sync.Locker package sync // import "sync" type Locker interface { Lock() Unlock() } A Locker represents an object that can be locked and unlocked.
Go Version: go1.19
Locker Methods
You can use thesync.Locker.Lock17方法, Listing 13.33, to lock the shared resource. Once a resource is locked, no other goroutine can access the resource until it is unlocked.
Listing 13.33 Thesync.Locker.LockMethod
$ go doc sync.Mutex.Lock package sync // import "sync" func (m *Mutex) Lock() Lock locks m. If the lock is already in use, the calling goroutine blocksuntil the mutex is available.
until the mutex is available.Go Version: go1.19
You can use thesync.Locker.Unlock18方法, Listing 13.34, to unlock the shared resource. Once a resource is unlocked, other goroutines can access the resource.
Listing 13.34 Thesync.Locker.UnlockMethod
$ go doc sync.Mutex.Unlock package sync // import "sync" func (m *Mutex) Unlock() Unlock unlocks m. It is a run-time error if m is not locked on entry to
Go Version: go1.19
Using a Mutex
The most basic mutex available in Go is thesync.Mutextype, Listing 13.35. Thesync.Mutexuses a basic binary semaphore lock. This means that only one goroutine can access the resource at a time.
Listing 13.35 Thesync.MutexType
$ go doc sync.Mutex package sync // import "sync" type Mutex struct { // Has unexported fields. } A Mutex is a mutual exclusion lock. The zero value for a Mutex is anunlocked mutex. A Mutex must not be copied after first use. func (m *Mutex) Lock() func (m *Mutex) TryLock() bool func (m *Mutex) Unlock()
Go Version: go1.19
To use async.Mutex, you need to wrap the areas of code that you want to synchronize access to by first locking thesync.Mutexand then unlocking it. For example, in the second goroutine in Listing 13.36, a mutex is being used to lock access around writing values into thedatamap.
Listing 13.36 Locking Resources with async.Mutex
// launch a goroutine to // read data from the mapgo func() {// lock the mutexmu.Lock()// loop through the map // and print the keys/valuesfork,v:=rangedata{fmt.Printf("%d: %v\n",k,v) }// unlock the mutexmu.Unlock() }()// launch a goroutine to // put data in the mapgo func() {fori:=0;i<10;i++ {// lock the mutexmu.Lock()// loop putting data in the mapdata[i] =true// unlock the mutexmu.Unlock() }// cancel the contextcancel() }()
By locking access to the shared resource, you can ensure that only one goroutine at a time can access the resource. Our test output, Listing 13.37, confirms that the shared resource is only accessed by one goroutine at a time with a successful exit.
Listing 13.37 Passing Race Detector Tests
$ go test -v -race === RUN Test_Mutex === PAUSE Test_Mutex === CONT Test_Mutex 9: true --- PASS: Test_Mutex (0.00s) 0: true 2: true 5: true 8: true 7: true 1: true PASS 3: true 4: true 6: true ok demo 0.810s
Go Version: go1.19
RWMutex
通常,应用程序读取一个共享资源of writing to them. Thesync.Mutexis a very heavy-weight locking mechanism. Access to a shared resource, whether it be a read or write, is blocked until the resource is unlocked. Only one goroutine can access a shared resource at a time.
When you want to be able to both read and write to a shared resource, you need to use async.RWMutex, Listing 13.38. Thesync.RWMutexis a lighter-weight locking mechanism. Async.RWMutexcan allow many goroutines to read from the resource at the same time, but only one goroutine can write to the resource at a time.
Listing 13.38 Thesync.RWMutexType
$ go doc sync.RWMutex package sync // import "sync" type RWMutex struct { // Has unexported fields. } A RWMutex is a reader/writer mutual exclusion lock. The lock can be heldby an arbitrary number of readers or a single writer. The zero value fora RWMutex is an unlocked mutex. A RWMutex must not be copied after first use. If a goroutine holds a RWMutex for reading and another goroutine mightcall Lock, no goroutine should expect to be able to acquire a read lockuntil the initial read lock is released. In particular, this prohibitsrecursive read locking. This is to ensure that the lock eventually可用;锁阻塞调用不包括东北w readers fromacquiring the lock. func (rw *RWMutex) Lock() func (rw *RWMutex) RLock() func (rw *RWMutex) RLocker() Locker func (rw *RWMutex) RUnlock() func (rw *RWMutex) TryLock() bool func (rw *RWMutex) TryRLock() bool func (rw *RWMutex) Unlock()
Go Version: go1.19
Thesync.RWMutexoffers two additional methods beyond those of thesync.Lockerinterface. You can use thesync.RWMutex.Rlock19andsync.RWMutex.RUnlock20方法s to lock the resource for reading. Thesync.RWMutex.Lock21andsync.RWMutex.Unlock22方法s are used to lock the resource across all goroutines for writing.
In Listing 13.39, we update the goroutine that is reading the resource to use thesync.RWMutex.Rlock方法instead of thesync.Mutex.Lock方法. This will allow for many goroutines to read from the resource at the same time.
Listing 13.39 Using async.RWMutex
// launch a goroutine to // read data from the mapgo func() {// lock the mutexmu.RLock()// loop through the map // and print the keys/valuesfork,v:=rangedata{fmt.Printf("%d: %v\n",k,v) }// unlock the mutexmu.RUnlock() }()
$ go test -v -race === RUN Test_RWMutex === PAUSE Test_RWMutex === CONT Test_RWMutex 4: true 5: true 6: true --- PASS: Test_RWMutex (0.00s) 7: true 9: true 0: true 1: true PASS 8: true 2: true 3: true ok demo 0.917s
Go Version: go1.19
The tests in Listing 13.39 continue to pass, but the performance of the program is improved by allowing multiple goroutines to read from the shared resource instead of arbitrarily locking all goroutines all at once.
Improper Usage
When using eithersync.Mutexorsync.RWMutex, you must take care in making sure to lock and unlock in the proper order.
Consider Listing 13.40. We have async.Mutex, and we attempt to callsync.Mutex.Locktwice.
Listing 13.40 Attempting to Lock async.MutexTwice
funcTest_Mutex_Locks(t*testing.T) {t.Parallel()// create a new mutexvarmu sync.Mutex// lock the mutexmu.Lock()fmt.Println("locked. locking again.")// try to lock the mutex again // this will block/deadlock // because the mutex is already locked // and the lock was not releasedmu.Lock()fmt.Println("unlocked twice") }
The result is the program will deadlock and crash, as shown in Listing 13.41. The reason is that a call tosync.Mutex.Lockblocks until thesync.Mutex.Unlock方法is called. Because we have already locked thesync.Mutex, the second call tosync.Mutex.Lockblocks indefinitely because it is never unlocked.
清单13.41恐慌而试图打开一个一个lready-Unlockedsync.Mutex
$ go test -v -timeout 10ms === RUN Test_Mutex_Locks === PAUSE Test_Mutex_Locks === CONT Test_Mutex_Locks locked. locking again. panic: test timed out after 10ms goroutine 33 [running]: testing.(*M).startAlarm.func1() /usr/local/go/src/testing/testing.go:2029 +0x8c created by time.goFunc /usr/local/go/src/time/sleep.go:176 +0x3c goroutine 1 [chan receive]: testing.tRunner.func1() /usr/local/go/src/testing/testing.go:1405 +0x45c testing.tRunner(0x140001361a0, 0x1400010fcb8) /usr/local/go/src/testing/testing.go:1445 +0x14c testing.runTests(0x1400001e1e0?, {0x100ec9ea0, 0x1, 0x1},{0xe00000000000000?, 0x100cf5218?, 0x100ed2640?}) /usr/local/go/src/testing/testing.go:1837 +0x3f0 testing.(*M).Run(0x1400001e1e0) /usr/local/go/src/testing/testing.go:1719 +0x500 main.main() _testmain.go:47 +0x1d0 goroutine 4 [semacquire]: sync.runtime_SemacquireMutex(0x1400000e018?, 0x20?, 0x17?) /usr/local/go/src/runtime/sema.go:71 +0x28 sync.(*Mutex).lockSlow(0x14000012140) /usr/local/go/src/sync/mutex.go:162 +0x180 sync.(*Mutex).Lock(...) /usr/local/go/src/sync/mutex.go:81 demo.Test_Mutex_Locks(0x0?) ./demo_test.go:25 +0x130 testing.tRunner(0x14000136340, 0x100e25298) /usr/local/go/src/testing/testing.go:1439 +0x110 created by testing.(*T).Run /usr/local/go/src/testing/testing.go:1486 +0x300 exit status 2 FAIL demo 0.527s
Go Version: go1.19
Worse than a deadlock caused by waiting for a lock that will never be unlocked is unlocking a lock that has not been locked.
In Listing 13.42, the result is a fatal error that crashes the application. The reason is that we have not locked thesync.Mutexbefore attempting to unlock it.
Listing 13.42 A Panic while Trying to Unlock an Unlockedsync.Mutex
funcTest_Mutex_Unlock(t*testing.T) {t.Parallel()// create a new mutexvarmu sync.Mutex// unlock the mutexmu.Unlock() }
$ go test -v === RUN Test_Mutex_Unlock === PAUSE Test_Mutex_Unlock === CONT Test_Mutex_Unlock fatal error: sync: unlock of unlocked mutex goroutine 18 [running]: runtime.throw(0x104573b02?, 0x1400005af18?) /usr/local/go/src/runtime/panic.go:992 +0x50 fp=0x1400005aee0
Go Version: go1.19
Wrapping Up Read/Write Mutexes
While there are pitfalls and areas of concern when using mutexes, such as deadlocks and improper usage,sync.Mutexandsync.RWMutexare excellent tools for protecting shared resources. They are also the most commonly used locking mechanisms in Go.