"Goroutines are unique to Go (though some other languages have a concurrency
primitive that is similar). They’re not OS threads, and they’re not exactly green
threads—threads that are managed by a language’s runtime—they’re a higher level of
abstraction known as coroutines."
Hey, I was able to understand this statement to a certain level but can someone make it a bit more clear. I can't wrap my head around what exactly a coroutine is.
I am referring the book 'Concurrency in Go' by Katherine Cox-Buday. Additionally, if you guys have any suggestions for references do list them down.
IMO, a coroutine implies supporting of explicit means for transferring control to another coroutine. That is, the programmer programs a coroutine in a way when they decide when a coroutine should suspend execution and pass its control to another coroutine (either by calling it or by returning/exiting (usually called yielding)).
Go's "goroutines" are another thing: they implicitly surrender control at certain indeterminate points1 which happen when the goroutine is about to sleep on some (external) resource like I/O completion, channel send etc. This approach combined with sharing state via channels enables the programmer to write the program logic as a set of sequential light-weight processes which removes the spaghetti code problem common to both coroutine- and event-based approaches.
Regarding the implementation, I think they're quite similar to the (unfortunately not too well-known) "State Threads" library, just quite lower-level (as Go doesn't rely on libc or things like this and talks directly to the OS kernel) — you could read the introductory paper for the ST library where the concept is quite well explained.
Update from 2023-08-25: Russ Cox has written a good essay on why a standard coroutine package for Go would be useful, and how it could look like.
1 In fact, these points are less determinate than those of coroutines but more determinate than with true OS threads under preemptive multitasking, where each thread might be suspended by the kernel at any given point in time and in the flow of the thread's control.
Update on 2021-05-28: actually, since Go 1.14, goroutines are scheduled (almost) preemptively.
It should be noted though, that it's still not that hard-core preemption a typical kernel does to the threads it manages but it's quite closer than before; at least it's now impossible for a goroutine to become non-preemptible once it enters a busy loop.
Not quite. The Go FAQ section Why goroutines instead of threads? explains:
Goroutines are part of making concurrency easy to use. The idea, which has been around for a while, is to multiplex independently executing functions—coroutines—onto a set of threads. When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won't be blocked. The programmer sees none of this, which is the point. The result, which we call goroutines, can be very cheap: they have little overhead beyond the memory for the stack, which is just a few kilobytes.
To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly minted goroutine is given a few kilobytes, which is almost always enough. When it isn't, the run-time grows (and shrinks) the memory for storing the stack automatically, allowing many goroutines to live in a modest amount of memory. The CPU overhead averages about three cheap instructions per function call. It is practical to create hundreds of thousands of goroutines in the same address space. If goroutines were just threads, system resources would run out at a much smaller number.
I work at one of those large companies where migration work never stops. We recently acquired a few other companies. To coalesce the platforms of multiple companies, we're rewriting a big chunk of our codebase in Go. The new platform itself is also being built from scratch in Go.
But the catch is we haven't historically been a Go shop. A lot of folks are coming from Python and Kotlin backends. So in our knowledge-sharing channel, we constantly see feature comparisons across these languages.
One thing that came up recently is how hard structured concurrency feels in Go. go func() is unstructured by default unless you wire it up with sync primitives like WaitGroup. A bunch of people also pointed out how Python’s TaskGroup or Kotlin’s coroutineScope make cancellation feel trivial. In Go, cancellation semantics require explicit context checking and manual bailouts.
We had some interesting internal discussions around this that I think would be valuable for others going through similar journey.
So I summarized some of the key points that came up and added a few examples. I’m curious how others approach structured concurrency in Go. How do you avoid the usual leaks that happen with manual plumbing?
https://rednafi.com/go/structured-concurrency/
I think I know part of the answer. I tried to summarize my understanding of the differences, in order of importance, between asyncio tasks and goroutines:
1) Unlike under asyncio, one rarely needs to worry that their goroutine will block for too long. OTOH, memory sharing across goroutines is akin to memory sharing across threads rather than asyncio tasks since goroutine execution order guarantees are much weaker (even if the hardware has only a single core).
asyncio will only switch context on explicit await, yield and certain event loop methods, while Go runtime may switch on far more subtle triggers (such as certain function calls). So asyncio is perfectly cooperative, while goroutines are only mostly cooperative (and the roadmap suggests they will become even less cooperative over time).
A really tight loop (such as with numeric computation) could still block Go runtime (well, the thread it's running on). If it happens, it's going to have less of an impact than in python - unless it occurs in mutliple threads.
2) Goroutines are have off-the-shelf support for parallel computation, which would require a more sophisticated approach under asyncio.
Go runtime can run threads in parallel (if multiple cores are available), and so it's somewhat similar to running multiple asyncio event loops in a thread pool under a GIL-less python runtime, with a language-aware load balancer in front.
3) Go runtime will automatically handle blocking syscalls in a separate thread; this needs to be done explicitly under asyncio (e.g., using run_in_executor).
That said, in terms of memory cost, goroutines are very much like asyncio tasks rather than threads.
I suppose you could think of it working that way underneath, sure. It's not really accurate, but, close enough.
But there is a big difference: in Go you can write straight line code, and all the I/O blocking is handled for you automatically. You can call Read, then Write, then Read, in simple straight line code. With Python asyncio, as I understand it, you need to queue up a function to handle the reads, rather than just calling Read.
For anyone who's tried both Go and Python async (ex uvloop + sanic, apistar, etc) for their webapp, what are the pros and cons of working in each language?
Pretty much that. I was thinking about Go's goroutines and that they are (imo) a great way to make multi-threading easy; but that left me thinking... how would you call goroutines in another language? "goroutine" is a fine name, and "go" a fine syntax for it, but it's obviously tied to Go and feels wrong to use it in a language that has nothing to do with Go.
Hello, Gophers!!!
I was browsing through HackerNews and saw a post about how their company is using stackfull coroutine with C/C++. This got me wondering are there advantages of coroutine above goroutines in 2023?
Thank you!!
I mean, I get that when we spawn a go routine the runtime generates a green thread which is a lightweight thread... but doesn't this need ultimately a thread to run?
So if a green thread depends on a thread, a goroutine is not a thread but there's no big difference between of being a thread and depending on a thread.
What I'm getting wrong here? What's the actual benefit besides not depending on a specific OS?
With regards to memory overhead, scheduling efficiency, context switching etc? does JVM vs Native play any role? I want to know some differentiating factors so that I can choose between them to build my concurrent app backend.
I wrote this article and it took me 10 months to come up with the most simple explanation. Please share your feedback. Here's the link : https://albatross.hashnode.dev/coroutines-in-python