Golang Mutex to Lock Specific Variable/Map

I'm a little confused on how mutex's work in Golang, even though I've used them before.

Here are my questions:

1. What exactly does a mutex lock? (How) Do you use it to lock a specific variable only?

2. Should I use channels instead of a mutex?

3. Is there a difference between a mutex and a locker?

I'm developing a highly concurrent website with golang, and I need to manage each person's wallet at different times and I am trying to avoid any races in my program. For example, if my program wants to add 500 credits to a user, it will read the current balance for the user (from firebase) and add 500 then update the value. But if it does this twice for some reason, there may be an incorrect change to the user's wallet.

What is a Mutex?

In general, a "mutual exclusion" construct (or mutex) helps with concurrency control. Languages that define mutexes let programmers define a critical section of code that can only be entered by a single thread of execution. Here is a simple example of using mutexes in Go. Here is a bit more detailed example of using mutexes.

Mutex or Channel?

When deciding whether to use a mutex or channel based design in your Go app, the choices aren't always terribly clear. This wiki article from the Go github repo has the following advice:

Channel: passing ownership of data,
distributing units of work,
communicating async results

Mutex: caches, state

Mutex or sync.Locker?

As @JimB pointed out, the sync.Mutex type in Go satisfies the sync.Locker interface type. Notice how sync.Mutex has Lock() and Unlock() methods? So to Go, a sync.Mutex is a sync.Locker.

For more help with Go interfaces, check out this great blog post.

1. A Mutex only locks itself. It's up to you to decide what that lock signifies in your code.
2. Use channels for synchronizing and communicating between goroutines. Use a mutex to provide "mutual exclusion" around a single logical resource.
3. A mutex satisfies the sync.Locker interface. Something that requires a sync.Locker could use a sync.Mutex or a sync.RWMutex interchangeably.

Synchronization primitives aren't related to the concept of preventing duplicate transactions. Correct use of synchronization will only prevent data races in your program.

If the state is not in memory. You really don't need synchronous locks. But let's say all of the users wallets are inside of one Map. You would need one because concurrent writes will cause a race condition.