In 2006, Edward A. Lee wrote The Problem With Threads (PDF), in which he observes that threads remove determinism and open the door to subtle yet deadly bugs. While the problems are maybe manageable on single core systems, threads on multicore systems are likely to magnify the problems out of control.

According to Wikipedia, coroutines are “program components that generalize subroutines to allow multiple entry points and suspending and resuming of execution at certain locations”. Coroutines are well-suited for implementing more familiar program components such as cooperative tasks, iterators, infinite lists, and pipes. Coroutines are more generic than subroutines. The start of a coroutine is the first point of entry, and places within a coroutine following returns (yields) are subsequent points of entry. Coroutines are also a lot faster than processes or threads switch, since there is no OS kernel involvement for the operation.

Even though coroutines are supported in some high-level languages, there doesn’t seem to be an standard implementation of them in C or C++. The first time I heard about coroutines were in Lua. Since then, I’ve been trying to find a good solution for using them in C. Simon Tatham proposes a way of implementing them with a combination of subroutines and macros, but I think that, even creative and clean, this is a dirty approach for real code. What about handling with errors in the code? I still have nightmares when I have some problem to debug in STL-based code. Cryptic, the least.

Due to the limitations of standard C libraries, some authors have written their own libraries for coroutines:

• Libtask: a Coroutine Library for C and Unix. It uses the context functions if they are provided by the native C library; otherwise it provides its own implementations for ARM, PowerPC, Sparc, and x86.
• Portable Coroutine Library (PCL): Easily portable on almost every Unix system and on Windows. It can use either the ucontext.h functionalities ( getcontext()/makecontest()/swapcontext() ) or the standard longjmp()/setjmp().
• libCoroutine (a small, portable coroutine implementation): For FreeBSD, Linux, OS X PPC and x86, SunOS, Symbian and others.

Co-routines *shudder*. They were invented by one of my lecturers, I don’t think _anyone_ thought they were a good thing after he lectured us on them; they are a poor-man’s multi-tasking and threads.

“…he observes that threads remove determinism and open the door to subtle yet deadly bugs. While the problems are maybe manageable on single core systems, threads on multicore systems are likely to magnify the problems out of control.”

You are not going to find anything more than a simple system these days which doesn’t have some sort of concurrency issues, whether in multiple threads or applications. Using co-routines doesn’t really help; event loops are a much better solution if you do not want to use threads. Single-core systems don’t really improve your behaviour with threads, since the scheduler can switch at arbitrary points. With threads you may have concurrency issues, but the other options also have issues with live- or dead-lock. Solving concurrency issues isn’t all that hard, especially with a language which makes it easy (Java makes managing concurrency adequately very easy and well with not a lot more complexity).

Ultimately, programmers who don’t know how to solve concurruncy issues probably need to learn how to, rather than coming up with systems that help a bit for a while, but don’t help in the long run

Co-routines look pretty much like cooperative multitasking. It sounds like it is pretty much useless on multi-core architectures, except if you only want one core to be used by a program at a time…

Isn’t one purpose of threads to scale across multiple CPUs? Can coroutines server this purpose?

Why not have threads and coroutines (or microthreads)? Let’s take the advantages of both and get multiple CPUs with threads while dividing the program in thousands of small coroutines. Please have a look at http://subdivi.de/~helmut/libmuth/ if you’re interested (feedback is welcome).

I don’t understand what you mean with “While the problems are maybe manageable on single core systems, threads on multicore systems are likely to magnify the problems out of control.” If the threading mechanisms are correctly implemented the problems are exactly the same. They possibility to run into one is just higher with real parallel execution.

Dispatching x microthreads to y kernel threads isn’t easy and probably impossible to implement as a library. You need a virtual machine like Erlang.

Microthreads (or coroutines) are just an architectural thing and doesn’t help with speed or scalability.

[...] Original post by Planet Debian [...]

“Machine independent implementation of Cooperative Multi-threading in C”
By Frans Faase ( http://www.iwriteiam.nl/Ha_cmt.html ) seems to be a good link too:

“One would expect that to implement any form of multi-threading or multi-tasking, it would be required to use some kind of low-level machine programming, or at least to have access to some system calls of the operation system. Here we want to show that some form of multi-threading can be implemented in C that is completely machine and operating system independent. It requires some additional coding, but with using of some cleverly preprocessor symbols, the C preprocessor can be used to do most of the work. The Contiki operating system for 8-bit computers makes us of Protothreads, which are very similar to the method described here. “