Why Goroutine (coroutines) can handle a large concurrent?

 

In simple terms: coroutine very lightweight , can perform hundreds of thousands of coroutine in a process, still maintaining high performance.

Processes, threads, coroutines relationship and differences:

  • The process has its own independent stack and heap, the heap is neither shared nor shared stack, the process by the operating system scheduler.
  • Thread has its own independent stack and heap share, shared stack, the stack does not share, increased from the operating system thread scheduling (standard thread yes).
  • Coroutine shared heap and like threads, not shared stack, coroutine display scheduling coroutine code by the programmer.

The difference between heap and stack See: http://www.cnblogs.com/ghj1976/p/3623037.html 

Difference coroutine and threads are: coroutine avoid meaningless schedule, which can improve performance, but because the programmer must take responsibility for their own schedule.

 

Coroutine execution requires minimal stack memory (about 4 ~ 5KB), by default thread stack size is 1MB.

goroutine is a piece of code, a function entry, and in the heap a assigned to the stack . So it is very cheap, we can easily create tens of thousands of goroutine, but they are not scheduled by the operating system.

And all other concurrent framework of the same coroutine, goroutine in the so-called "no lock" the advantage is only valid in a single thread, if $ GOMAXPROCS> 1 and between coroutine need to communicate, Go runtime lock will be responsible for the protection of data, which is why the sieve.go such examples in the multi-CPU multi-threading but slower.

 

http://my.oschina.net/Obahua/blog/144549

A key feature of goroutine is their consumption; create their initial cost is very low memory (in stark contrast to the need for traditional POSIX threads 1 to 8MB of memory) and resources dynamically grow and shrink according to occupancy. This makes goroutine demand will increase or reduce the memory footprint from the beginning of 4096 bytes of the initial stack memory footprint, without having to worry about the depletion of resources.

To achieve this goal, the linker (5l, 6l and 8l) inserts a preamble before each function, the preface checks before the function is called to determine whether the current resources to meet demand (Note 1) the function is called. If not, the call runtime.morestack to allocate a new stack pages (Note 2), copy parameters function from the caller of the function there, and then returns control to the caller. At this point, we can safely call has the function of. When the function is finished, things did not end, the function returns the argument has been copied to the stack frame of the caller, and then release the unused stack space.

Through this process, the effective implementation of the unlimited use of stack memory. Assuming you are not constantly back and forth between the two stacks, colloquially called stack split, then the price is very cheap.

 

References:

[Translation] Why goroutine stack memory infinite? 
http://my.oschina.net/Obahua/blog/144549

Processes, threads and coroutines understanding 
http://blog.leiqin.name/2012/12/02/%E8%BF%9B%E7%A8%8B%E3%80%81%E7%BA%BF%E7 % A8% 8B% E5% 92 % 8C% E5% 8D% 8F% E7% A8% 8B% E7% 9A% 84% E7% 90% 86% E8% A7% A3.html

Coroutine stack frame size traps 
http://blog.csdn.net/huyiyang2010/article/details/6104891

Coroutine its implementation 
http://www.cnblogs.com/foxmailed/archive/2014/01/08.html

goroutine system knowledge behind 
http://www.sizeofvoid.net/goroutine-under-the-hood/

Guess you like

Origin www.cnblogs.com/deepalley/p/12003365.html