|
|
|
|
|
by roncesvalles
97 days ago
|
|
Exactly, reading TFA and its prequel, can't shake the feeling that the author doesn't really understand concurrency. The main purpose of synchronization is creating happens-before (memory/cache coherence) relationships between lines of code that aren't in the same program order. Go channels are just syntactic sugar for creating these happens-before relationships. Problems such as deadlocks and races (at least in the way that TFA calls them out) are irreducible complexity if you're executing two sequences of logical instructions in parallel. If you're passing data in whatever way, there is no isolation between those two sequences. All you can enforce is degrees of discipline. It's typical AI slop. I'd recommend for the author (or anyone else) to watch Jenkov's course[1] first if they have an honest interest in the topic. [1] https://www.youtube.com/playlist?list=PLL8woMHwr36EDxjUoCzbo... |
|
Software Transactional Memory or the same concept in any old relational database don't give you deadlocks.
And there's a lot of 'discipline' you can enforce with the typesystem automatically, if your language has a strong enough typesystem. Look up session types for more.