1 Why Threads are a Bad Idea (for most purposes) based on a presentation by John Ousterhout Sun Microsystems Laboratories Threads!

2 Threads give us: multiple execution streams Threads! Concurrency during execution  OSes use a kernel thread per user process  big computations can be divided among separate threads  but there is only speed up if you have a CPU for each thread  if single processing system, no time gain, just gain a lot of context switches

3 Threads give us: multiple execution streams Threads! Concurrency during blocking  process an I/O request in a separate thread  then overlap I/Os  i.e., when the thread blocks, do other work in another thread  works great in GUIs too -- have a thread to handle user actions  even if only one CPU, this works

4 Threads give us: logical control flow Threads!  multiple threads, but each thread is a single flow of execution  if the thread blocks, and another gets scheduled (or not!), the blocked thread’s stack is intact  the thread is all set to resume when offered the chance  this is a very comfortable and familiar abstraction!

5 Threads give us: Threads! Let the argument begin! One side says:  Spawning threads is easy…  …synchronization, now that’s hard!

6 Threads give us: Threads!  shared storage must be protected  mutexes, semaphores, monitors (oh my!)  non-blocking strategies  Read-Copy-Update & Hazard Pointers (hazard?!?)  re-entrant functions and libraries  data races and deadlock  difficult to program, hard to debug (Eraser showed us that)  local lock round trip = instructions  and as we’ll see with SEDA -- poor scalability!

7 Threads give us: Threads! And the biggest disadvantage of threads: Concurrency whether you need it or not!  what if all you need is non-blocking I/O?  or fast GUI response time?  what if you only have one processor?  if you use threads, you have to suffer the slings and arrows of synchronization  lock acquisition, lock contention, context switches

8 Event Driven Design gives us: 1 thread! an opposite philosophy  ONLY ONE THREAD!  an application is interested in certain events  rather than give work to a thread, code and call an event-handler to handle each particular event  app registers interest in each event, which essentially means: “when this event occurs, call this event-handler”  the app tells the environment to inform it when something happens, then app reacts

event_driven_programming.html 9 Event Driven Design gives us: events  the Agent is usually is a set of library functions  registration is also a library call  the Agent runs an event loop, ‘sensing’ events  when an event occurs, the event loop makes a callback to the event handler

10 Event Driven Design gives us: control  event dispatch can be implemented in different ways, varying in complexity, for example:  simple polling for events in a case statement that invokes event handlers  an event table that stores event registrations; do a lookup on the table to find which handler to invoke  detected events get placed on an event queue for the event’s handler  the current state of event queues can be used to make scheduling decisions

11 Event Driven Design gives us: control  event queues give us control over which events are handled when  unlike threads, in which the thread scheduler is part of a threads package or part of the OS, with events, the application can control the scheduling of handling events  this control is a key element of scalability! (as we’ll see with SEDA)

12 Event Driven Design gives us: 1 issue!  BUT event-driven I/O is not so straightforward!  here is the other side of the argument  the initial invocation of the event handler CAN’T block!  Only 1 thread!  It must return!

13 + Bottom Line Threads!  if you don’t need concurrency, then use events  faster!  no locks  no context switches  easier to program  if you can and will use concurrency, then use threads!  e.g., multiple CPUs