When you program concurrently the variables are exposed being shared

Question

When you program concurrently the variables are exposed being shared

and that is where the channel comes in to ensure communication in a safe way in a competitive scenario.
In Go it is possible to use the synchronization primitives and this is very interesting because he did not eliminate this possibility, the language allows its use, in the past we did not have Maps to work in a competing environment, for this to be possible we had to implement and see just how could we do this? Using Mutex ... This is an implementation that I did in the past https://gist.github.com/jeffotoni/13160dcac45068f31d56193cd0cbbe49 and just below in the answer another solution using sync.Map.
The examples in the post depict to take care and reflect more on primitives using Mutex and Channel, and that in some scenarios it is interesting to use primitives instead of channel, super valid from his point of view, he needed to lower the level even more in his projects .
It will arrive at a moment that will come up against GC do Go in the memory heaps and then the conversation starts to get even more interesting.
Remembering that Go is a new lang, which is maturing and advancing very fast, it has several points that need to improve as in any other lang.
Now, like Go community, I'm sure there are few like ours... 🥳🥳🥳🥳
but
But we know that the use of sync.Mutex when we have thousands of goroutines the performance is affected, making a very simple benchmarking to understand but read this post
https://stackoverflow.com/questions/57562606/why-does-sync-mutex-largely-drop-performance-when-goroutine-contention-is-more-t

0

16.02.2020

1 ответов

17 просмотров

B · Accepted Answer

B

thanks I get the difference between channels and concurrency primitives, I just don't really understand the example in the premise of the article

0

17.02.2020

Похожие чаты

When you program concurrently the variables are exposed being shared

1 ответов

Похожие вопросы