Introduction to Event-Based Concurrency

Thus far, we’ve written about concurrency as if the only way to build concurrent applications is to use threads. Like many things in life, this is not completely true. Specifically, a different style of concurrent programming is often used in both GUI-based applications“Why Threads Are A Bad Idea (for most purposes)” by John Ousterhout. Invited Talk at USENIX ’96, San Diego, CA, January 1996. A great talk about how threads aren’t a great match for GUI-based applications (but the ideas are more general). Ousterhout formed many of these opinions while he was developing Tcl/Tk, a cool scripting language and toolkit that made it 100x easier to develop GUI-based applications than the state of the art at the time. While the Tk GUI toolkit lives on (in Python for example), Tcl seems to be slowly dying (unfortunately). as well as some types of internet servers“Flash: An Efficient and Portable Web Server” by Vivek S. Pai, Peter Druschel, Willy Zwaenepoel. USENIX ’99, Monterey, CA, June 1999. A pioneering paper on how to structure web servers in the then-burgeoning Internet era. Read it to understand the basics as well as to see the authors’ ideas on how to build hybrids when support for asynchronous I/O is lacking.. This style, known as event-based concurrency, has become popular in some modern systems, including server-side frameworks such as Node.js“Node.js Documentation” by the folks who built node.js. Available: nodejs.org/api. One of the many cool new frameworks that help you readily build web services and applications. Every modern system’s hacker should be proficient in frameworks such as this one (and likely, more than one). Spend the time and do some development in one of these worlds and become an expert., but its roots are found in C/UNIX systems that we’ll discuss ahead.

The problem that event-based concurrency addresses is two-fold.

• The first is that managing concurrency correctly in multi-threaded applications can be challenging; as we’ve discussed, missing locks, deadlock, and other nasty problems can arise.
• The second is that in a multi-threaded application, the developer has little or no control over what is scheduled at a given moment in time; rather, the programmer simply creates threads and then hopes that the underlying OS schedules them in a reasonable manner across available CPUs.

Given the difficulty of building a general-purpose scheduler that works well in all cases for all workloads, sometimes the OS will schedule work in a manner that is less than optimal. And thus, we have event-based concurrency.

THE CRUX: HOW TO BUILD CONCURRENT SERVERS WITHOUT THREADS

How can we build a concurrent server without using threads, retain control over concurrency, and avoid some of the problems that seem to plague multi-threaded applications?