Sync
You can find all the code for this chapter here
We want to make a counter which is safe to use concurrently.
We'll start with an unsafe counter and verify its behaviour works in a single-threaded environment.
Then we'll exercise its unsafeness, with multiple goroutines trying to use the counter via a test, and fix it.
Write the test first
We want our API to give us a method to increment the counter and then retrieve its value.
Try to run the test
Write the minimal amount of code for the test to run and check the failing test output
Let's define Counter
.
Try again and it fails with the following
So to finally make the test run we can define those methods
It should now run and fail
Write enough code to make it pass
This should be trivial for Go experts like us. We need to keep some state for the counter in our datatype and then increment it on every Inc
call
Refactor
There's not a lot to refactor but given we're going to write more tests around Counter
we'll write a small assertion function assertCount
so the test reads a bit clearer.
Next steps
That was easy enough but now we have a requirement that it must be safe to use in a concurrent environment. We will need to write a failing test to exercise this.
Write the test first
This will loop through our wantedCount
and fire a goroutine to call counter.Inc()
.
We are using sync.WaitGroup
which is a convenient way of synchronising concurrent processes.
A WaitGroup waits for a collection of goroutines to finish. The main goroutine calls Add to set the number of goroutines to wait for. Then each of the goroutines runs and calls Done when finished. At the same time, Wait can be used to block until all goroutines have finished.
By waiting for wg.Wait()
to finish before making our assertions we can be sure all of our goroutines have attempted to Inc
the Counter
.
Try to run the test
The test will probably fail with a different number, but nonetheless it demonstrates it does not work when multiple goroutines are trying to mutate the value of the counter at the same time.
Write enough code to make it pass
A simple solution is to add a lock to our Counter
, ensuring only one goroutine can increment the counter at a time. Go's Mutex
provides such a lock:
A Mutex is a mutual exclusion lock. The zero value for a Mutex is an unlocked mutex.
What this means is any goroutine calling Inc
will acquire the lock on Counter
if they are first. All the other goroutines will have to wait for it to be Unlock
ed before getting access.
If you now re-run the test it should now pass because each goroutine has to wait its turn before making a change.
I've seen other examples where the sync.Mutex
is embedded into the struct.
sync.Mutex
is embedded into the struct.You may see examples like this
It can be argued that it can make the code a bit more elegant.
This looks nice but while programming is a hugely subjective discipline, this is bad and wrong.
Sometimes people forget that embedding types means the methods of that type become part of the public interface; and you often will not want that. Remember that we should be very careful with our public APIs, the moment we make something public is the moment other code can couple themselves to it. We always want to avoid unnecessary coupling.
Exposing Lock
and Unlock
is at best confusing but at worst potentially very harmful to your software if callers of your type start calling these methods.
![](https://quii.gitbook.io/~gitbook/image?url=https%3A%2F%2Fi.imgur.com%2FSWYNpwm.png&width=768&dpr=4&quality=100&sign=1a0868d9&sv=1)
This seems like a really bad idea
Copying mutexes
Our test passes but our code is still a bit dangerous
If you run go vet
on your code you should get an error like the following
A look at the documentation of sync.Mutex
tells us why
A Mutex must not be copied after first use.
When we pass our Counter
(by value) to assertCounter
it will try and create a copy of the mutex.
To solve this we should pass in a pointer to our Counter
instead, so change the signature of assertCounter
Our tests will no longer compile because we are trying to pass in a Counter
rather than a *Counter
. To solve this I prefer to create a constructor which shows readers of your API that it would be better to not initialise the type yourself.
Use this function in your tests when initialising Counter
.
Wrapping up
We've covered a few things from the sync package
Mutex
allows us to add locks to our dataWaitGroup
is a means of waiting for goroutines to finish jobs
When to use locks over channels and goroutines?
We've previously covered goroutines in the first concurrency chapter which let us write safe concurrent code so why would you use locks? The go wiki has a page dedicated to this topic; Mutex Or Channel
A common Go newbie mistake is to over-use channels and goroutines just because it's possible, and/or because it's fun. Don't be afraid to use a sync.Mutex if that fits your problem best. Go is pragmatic in letting you use the tools that solve your problem best and not forcing you into one style of code.
Paraphrasing:
Use channels when passing ownership of data
Use mutexes for managing state
go vet
Remember to use go vet in your build scripts as it can alert you to some subtle bugs in your code before they hit your poor users.
Don't use embedding because it's convenient
Think about the effect embedding has on your public API.
Do you really want to expose these methods and have people coupling their own code to them?
With respect to mutexes, this could be potentially disastrous in very unpredictable and weird ways, imagine some nefarious code unlocking a mutex when it shouldn't be; this would cause some very strange bugs that will be hard to track down.
Last updated