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 <pengyu...@gmail.com> 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+unsubscr...@googlegroups.com. > 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.
