Concurrency issues
Many issues, of course, but Go tries to take care of them. Channel send and receive are atomic. The select statement is very carefully defined and implemented, etc.
But goroutines run in shared memory, communication networks can deadlock, multithreaded debuggers suck, and so on.
Go gives you the primitives
Don’t program the way you would in C [...]
Concurrency issues
Many issues, of course, but Go tries to take care of them. Channel send and receive are atomic. The select statement is very carefully defined and implemented, etc.
But goroutines run in shared memory, communication networks can deadlock, multithreaded debuggers suck, and so on.
Go gives you the primitives
Don’t program the way you would in C or C++ or even Java.
Channels give you synchronization and communication both, and that makes them powerful but also easy to reason about if you use them well.
The rule is:
Do not communicate by sharing memory.
Instead, share memory by communicating. The very act of communication guarantees synchronization!
The model
For instance, use a channel to send data to a dedicated server goroutine. If only one goroutine at a time has a pointer to the data, there are no concurrency issues.
This is the model we advocate for programming servers, at least. It’s the old “one thread per client” approach, generalized – and used by us since the 1980s. It works very well.
Related posts:
Leave Your Response