The references in the Wikipedia article have a lot of overview detail: https://en.wikipedia.org/wiki/Go_(programming_language)#Concurrency:_goroutines_and_channels
I’m not convinced Node.js or Go are inherently more efficient than multithreading. Due to the overhead of repeating operating system functionality of scheduling work there may be cases where these languages are less efficient. The win for Node.js and Go is simpler concurrent code architecture. And, unlike Node.js, Go can also express parallel computation without threads or additional OS processes. Matt On Monday, January 22, 2018 at 3:25:15 PM UTC-6, Jesper Louis Andersen wrote: > > The ultra-short and precise answer to this question is: multithreading. > > Go implements a multithreaded runtime which maps goroutines to threads in > an N:M style. The idea is to obtain the efficiency of a libev model without > limiting yourself to a single core. The hard part is to manage the mapping > of goroutines to cores. I know of two posts which gives an excellent > overview: > > Daniel Morsing's blog: https://morsmachine.dk/index > > And a couple of posts by Jaana Burcu Doğan (@rakyll): > https://rakyll.org/scheduler/ > > Daniel's post is getting old, so suggest reading Jaana first, although I > still believe both are correct nowadays. > > Compared to the Node.js approach, the solution Go uses poses some distinct > advantages, namely: > > * More than one CPU core can work on the same program at the same time. > This improves parallelism. > * Programs can be written in a direct style, rather than as a set of event > callbacks. > * Scheduling can be pre-emptive rather than cooperative which can improve > program correctness and/or program processing latency to be more fair. > > The primary disadvantage of the Go approach is that explicit control over > the schedule is given over to the runtime. For smaller systems, you may be > able to handle this better yourself with a cooperative scheduler, albeit > for larger systems, this is extremely hard. The reason is that you need > only a single library import which is badly written and all of your system > is in jeopardy, whereas the pre-emptive Go scheduler will avoid such a > problem. Also, since Node.js programs only runs on a single core, the > system might need less locking around "shared" datastructures, which allows > some programs to run faster on a single core, given some specific workload > and luck in having everything fit on the single core's cache etc. > > I think, for modern architectures, that the Go approach is the correct > one, and that anything based on something like libev is eventually going to > be forgotten as a failed approach. But I've been known to be wrong on some > cases :) > > On Mon, Jan 22, 2018 at 9:32 PM Peng Yu <peng...@gmail.com <javascript:>> > wrote: > >> Hi, I'd like to know what go concurrency is based on. For example, nodejs >> is based on libev, making nodejs more efficient than using multithreading >> to handle concurrency. What is go based on to make go concurrency more >> effecient than multithreading? >> -- >> Regards, >> Peng >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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. For more options, visit https://groups.google.com/d/optout.
