Why Threads are a Bad Idea (for most purposes)

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

2. Threads! Threads give us: multiple execution streams Concurrency duringexecution • 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! Threads give us: multiple execution streams Concurrency duringblocking • 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! Threads give us: logical control flow • 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! Threads give us: #$!?(#!%@!! Let the argument begin! One side says: • Spawning threads is easy… • …synchronization, now that’s hard!

6. Threads! Threads give us: #$!?(#!%@!! • 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 = 1000+ instructions • and as we’ll see with SEDA -- poor scalability!

7. Threads! Threads give us: #$!?(#!%@!! 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

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 http://www.ferg.org/projects/ferg-event_driven_programming.html

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. Threads! + Bottom Line • 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