Thank you very much for your response, I think that at abstract level it is true.
When we go into more detail, we will that GO optimize to have Routine context ( that some kind of Thread context), I think that at the conception level it some kind of yeild (conception ) to start to GORoutine. But I read somewhere that GoRoutine optimize to create the thread when it dispatched ( at REGIGER level, they said that 3 Registers need to be handled to create new GoRoutine ). You see that although you could create the large number of GORoutine but almost of them have status BLOCK, and small number of them are running ( basing OS Thread ). For the sharing data between routines, I think that in mode RUNNING, there are Routine context that keep this sharing work smoothly. In my own opinion, it is one of the best choice to schedule job, Imagine that each time you start the GoRoutine, the new OS thread is created and start - I do not think that way cheap or lightweight routine as everyone said. > On Jun 22, 2016, at 20:53, Konstantin Khomoutov > <flatw...@users.sourceforge.net> wrote: > > On Wed, 22 Jun 2016 00:34:56 -0700 (PDT) > tu.p...@zalora.com wrote: > >> I think that the idea of Goroutine come from >> [https://en.wikipedia.org/wiki/Coroutine], > > This is hardly true: coroutines imply cooperative scheduling, where > each coroutine explictly relinquishes control to some other coroutine > (typically it's said it "yields" some intermediate result) without > actually returning. In contrast, goroutines behave much more like > OS-level threads in that the Go runtime scheduler is free to preempt any > goroutine at will at certain key points of their execution (presently > these include the event when a goroutine is about to block on a syscall > or call another Go function). Hence while it's not a "full" preemptive > scheduling which commodity operating systems apply to their OS-level > threads, it's still way more closer to it than the cooperative ("at > will") scheduling used by coroutines. > > One more point to this is that coroutines are usually considered as > being executed by a single thread of execution which is not true for > goroutines -- which, due to this reason, cannot safely access shared > data without locking, and must synchronize all such access or use > specific communication primitives -- channels. > > Go draws its approach to goroutines from a number of languages which > predates it, but ultimately this idea comes from [1]. > >> the number of Goroutines are mapped to OS Threads. > > It's more accurate to say that an arbitrary number of goroutines can be > mapped to an arbitrary number of OS threads, which is usually referred > to as "N x M scheduling", with N -- the number of goroutines -- > typically being way larger than M -- the number of OS threads undelying > them. > >> In my own opinion, Go maintain the Thread pool and task queue to >> dispatch the job. > > At a very abstract level, this is mostly true. > > [...] > > 1. https://en.wikipedia.org/wiki/Communicating_sequential_processes -- 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
