Great! I liked Mill's lecture. After having seen it, here's my favourite: *Clojure core.async*, lecture (45 mins). Rich Hickey discusses the motivation, design and use of the Clojure core.async library. He also talks about go. See https://www.infoq.com/presentations/clojure-core-async/ (lecture 22Nov2013) and https://clojure.org/news/2013/06/28/clojure-clore-async-channels (description). Additionally you can download the soundtrack from this as an mp3. Minutes into the lecture: 13.57 - CSP background 18.24 - The difference between blocking and parking. Also about IOC threads (Inversion of Control threads) 19.12 - The description of the difference between blocking and parking
About *blocking*, I have a blog note myself: https://www.teigfam.net/oyvind/home/technology/092-not-so-blocking-after-all/ - Disclaimer <https://www.teigfam.net/oyvind/home/#standard_disclaimer>: no money, ads, gifts in my blog notes. Only fun and expenses. fredag 27. november 2020 kl. 12:19:11 UTC+1 skrev b.ca...@pobox.com: > On Friday, 27 November 2020 at 10:32:11 UTC oyvin...@teigfam.net wrote: > >> Thread safety, concurrency safety, goroutines safety. The same stuff to >> me. >> >> It's important that concurrent goroutines don't interfere with each other >> in such a way that internal state is compromised by other goroutines. >> Typically through access to internal data, through pointers. >> > > Not just that, but also: > > - any global variables. Even reading an 'int' while some other goroutine > is updating it is unsafe; it may give undefined behavior. > > - concurrent read and write accesses to the same map or slice can cause > the program to panic. Note that map and slice values contain hidden > pointers inside them. So if two goroutines have the same map or slice > value, they are aliasing to the same underlying data. > > These can trip up people used to (say) Python, where such accesses are > atomic - primarily because of Python's Global Interpreter Lock. > > (There is sync.Map <https://golang.org/pkg/sync/#Map> which is > concurrency-safe, but if you need this, there's probably a better solution > in your architecture) > > >> If only go channels are used to communicate between goroutines, than that >> case is closed. That's one of the reasons they exist - also in other >> similar languages, with that aspect often based on CSP. >> > > Here's a video explaining how channels can replace various concurrency > primitives: it's worth getting your head around. > https://www.youtube.com/watch?v=5zXAHh5tJqQ > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5d850534-af12-4820-994b-e9eb728f2d5an%40googlegroups.com.
