Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How does Go caters to multi-core processor systems needs?

 
Palak Mathur
Ranch Hand
Posts: 342
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mark,

Welcome to the Ranch! I have gone through the documentation about Go on golang.org and the main reason cited in the FAQs is that it has been designed to work on multi-core systems. How does it differs from C in this respect? I think C is flexible enough to cater to these needs as well.
 
Mark Summerfield
author
Ranch Hand
Posts: 37
Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Palak,

Summary: Go's approach to concurrency is higher-level, easier, and much more flexible than C's.

C, C++, and Java provide support for concurrency using threads. Modern operating systems can distribute the work of threads across multiple processors and cores to maximize throughput. However, threads are relatively expensive to create and use quite a lot of resources. A desktop machine might struggle to run an application that uses just 10s of threads---and certainly one that uses 100+ threads.

Go takes a different approach. Go uses goroutines---these can be treated as if they were threads from the point of view of dividing up work to be done. However, goroutines are so lightweight that running 100s, 1000s, or even 10000s of goroutines on a single machine is perfectly possible. So what goroutines provide is much finer-grained concurrency than threads. (Under the hood the Go runtime system multiplexes goroutines onto one or a few threads.)

In addition, although Go provides low-level concurrent operations (such as atomic increment), and mid-level operations (such as mutexes), Go also provides a high-level a concurrency model called Communicating Sequential Processes (CSP). CSP allows programmers to synchronize goroutines and pass data between them using type-safe uni- or dual-directional pipelines that are much easier to program and reason about than the mid- and low-level facilities offered by C and some other languages.
 
atul khot
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark Summerfield wrote:Hi Palak,

Go takes a different approach. Go uses goroutines---these can be treated as if they were threads from the point of view of dividing up work to be done. However, goroutines are so lightweight that running 100s, 1000s, or even 10000s of goroutines on a single machine is perfectly possible. So what goroutines provide is much finer-grained concurrency than threads. (Under the hood the Go runtime system multiplexes goroutines onto one or a few threads.)


Is this something like multiple user level threads mapping to a single kernel level thread - I think Solaris works / maps pthreads like this
(Multiple user threads are time sliced onto a single kernel thread)?

Sorry if this is a messed up analogy...

If I am right, a question is - in case of solaris - the kernel architecture helps ensure performance - As goroutines would be entirely user space, what are the performance guarantees...
As switching context is some overhead

--- cheerio atul
 
Mark Summerfield
author
Ranch Hand
Posts: 37
Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is this something like multiple user level threads mapping to a single kernel level thread - I think Solaris works / maps pthreads like this
(Multiple user threads are time sliced onto a single kernel thread)?


Yes, that's my understanding of how the standard Go compiler works. (I think that GCC Go is different though.)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic