• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 343
Mac OS X Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 37
VI Editor Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 37
VI Editor Linux Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.)
 
reply
    Bookmark Topic Watch Topic
  • New Topic