I think this is the idiomatic way to implement this. It will lock the account every time you try to deposit to it (so other goroutines can't do it).
I think this is the idiomatic way to implement this. It will lock the account every time you try to deposit to it (so other goroutines can't do it).
http://golang.org/doc/effective_go.html#concurrency
"Do not communicate by sharing memory; instead, share memory by communicating.
This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance. But as a high-level approach, using channels to control access makes it easier to write clear, correct programs. "
E.g. An bank account is shared state (similar to a reference count) and the best approach is to put a mutex around it instead of fighting with channel synchronization.
"Reference counts MAY be best done by putting a mutex around an integer variable, for instance. BUT as a high-level approach, using channels to control access makes it easier to write clear, correct programs."
There is a difference between what someone with a background from other mainstream programming languages might think would be the best approach to locking (mutexes) and the idiomatic Go approach (unbuffered channels).