Win a copy of GANs in ActionE this week in the AI forum
or WebAssembly in Action in the JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

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
  • 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
  • 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
  • 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
  • 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.)
 
I am a man of mystery. Mostly because of this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!