Now it is making more sense. So GOMAXPROCS has no connection with the actual number of OS threads created to run goroutines. But it does determine how many of them are active at any given time. Also, a single OS thread can multiplex multiple goroutines, unless #LockOSThread() is invoked in which case that OS thread will exclusively run that goroutine to completion.
Thank you for explaining. On Mon, Oct 3, 2016 at 1:32 PM, Ian Lance Taylor <[email protected]> wrote: > On Mon, Oct 3, 2016 at 12:48 PM, 'SrimanthG' via golang-nuts > <[email protected]> wrote: > > I have another code snippet which hits the same problem and it does not > use > > sleep: https://play.golang.org/p/mUPCOFle4h > > All 10 goroutines are going beyond "runtime.LockOSThread()" on a single > OS > > thread. > > No, they are not. What is happening is that the 10 different > goroutines are running on 10 different OS threads. And furthermore > only one of those OS threads is running at one time. But there is > nothing to prevent the goroutine scheduler from flipping back and > forth between which goroutine, and therefore which thread, will run. > The goroutine scheduler is able to preempt any goroutine at a function > call point (among many other places that a goroutine can be > preempted). > > Ian > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
