I have not once had to use sync/atomic and I wrote and maintain a massive data aggregation and quantitative algorithm platform 100% in Go at work.
Channels in Go are not a function, they are a primitive type.
In contrast to semaphores aka. mutexes, channels are highly recommended since, when used correctly, they can serialize concurrent access very efficiently. Take care of how to use them - do not pass tiny amounts of work over channels, pass around a chunk of work and work in batches.
Normally the work you will do per item will greatly exceed the 90β250 ns it takes to move the item through the channel, so itβs just not worth worrying about.
Channels are slower than copy() for just shifting bytes, but in a simple scenario are about as fast as a naive self-made channel implementation using the sync package.
The choice of channels vs. mutexes is one of design, not implementation. BOTH use LOCK XCHG and pay the price.
Also, channels are blocking data structures. APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose. If you just want to synchronize access to shared memory then use a mutex. These are not good use-cases for channels to begin with.
As they say: Share memory by communicating, rather than communicating by sharing memory.
An easy example of this: Use a channel with a buffer of 1 to store the current number, fetch it from the channel when you need it, change it at will, then put it back for others to use.
That last example, where you store a single number in a channel, seems to contradict your recommendation to "not pass tiny amounts of work over channels?"
It's supposed to be an easy example of the concept of sharing memory by communicating and has nothing to do with the recommendation to not pass tiny amounts of tasks.
Channels in Go are not a function, they are a primitive type.
In contrast to semaphores aka. mutexes, channels are highly recommended since, when used correctly, they can serialize concurrent access very efficiently. Take care of how to use them - do not pass tiny amounts of work over channels, pass around a chunk of work and work in batches.
Normally the work you will do per item will greatly exceed the 90β250 ns it takes to move the item through the channel, so itβs just not worth worrying about.
Channels are slower than copy() for just shifting bytes, but in a simple scenario are about as fast as a naive self-made channel implementation using the sync package.
The choice of channels vs. mutexes is one of design, not implementation. BOTH use LOCK XCHG and pay the price.
Also, channels are blocking data structures. APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose. If you just want to synchronize access to shared memory then use a mutex. These are not good use-cases for channels to begin with.
As they say: Share memory by communicating, rather than communicating by sharing memory.
An easy example of this: Use a channel with a buffer of 1 to store the current number, fetch it from the channel when you need it, change it at will, then put it back for others to use.