1 / 13

Threads vs. Events: Making the Right Choice

Discover why threads might not be ideal for many purposes, explore the drawbacks of threads, and learn about the benefits of event-driven design in this insightful presentation by John Ousterhout at Sun Microsystems Laboratories. Gain insights into multiple execution streams, synchronization challenges, logical control flow, and scalability concerns. Find out how event-driven design offers a more efficient approach with better control and fewer drawbacks.

hadamson
Download Presentation

Threads vs. Events: Making the Right Choice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related