Processes, threads, green threads, protothreads, fibers, coroutines: what's the difference?

Question

I'm reading up on concurrency. I've got a bit over my head with terms that have confusingly similar definitions. Namely:

• Processes
• Threads
• "Green threads"
• Protothreads
• Fibers
• Coroutines
• "Goroutines" in the Go language

My impression is that the distinctions rest on (1) whether truly parallel or multiplexed; (2) whether managed at the CPU, at the OS, or in the program; and (3..5) a few other things I can't identify.

Is there a succinct and unambiguous guide to the differences between these approaches to parallelism?

Answer 1

OK, I'm going to do my best. There are caveats everywhere, but I'm going to do my best to give my understanding of these terms and references to something that approximates the definition I've given.

• Process: OS-managed (possibly) truly concurrent, at least in the presence of suitable hardware support. Exist within their own address space.
• Thread: OS-managed, within the same address space as the parent and all its other threads. Possibly truly concurrent, and multi-tasking is pre-emptive.
• Green Thread: These are user-space projections of the same concept as threads, but are not OS-managed. Probably not truly concurrent, except in the sense that there may be multiple worker threads or processes giving them CPU time concurrently, so probably best to consider this as interleaved or multiplexed.
• Protothreads: I couldn't really tease a definition out of these. I think they are interleaved and program-managed, but don't take my word for it. My sense was that they are essentially an application-specific implementation of the same kind of "green threads" model, with appropriate modification for the application domain.
• Fibers: OS-managed. Exactly threads, except co-operatively multitasking, and hence not truly concurrent.
• Coroutines: Exactly fibers, except not OS-managed.
• Goroutines: They claim to be unlike anything else, but they seem to be exactly green threads, as in, process-managed in a single address space and multiplexed onto system threads. Perhaps somebody with more knowledge of Go can cut through the marketing material.

It's also worth noting that there are other understandings in concurrency theory of the term "process", in the process calculus sense. This definition is orthogonal to those above, but I just thought it worth mentioning so that no confusion arises should you see process used in that sense somewhere.

Also, be aware of the difference between parallel and concurrent. It's possible you were using the former in your question where I think you meant the latter.