1 / 16

Threads, Events, and Reactive Objects

This overview explores the drawbacks of using threads for concurrency and the benefits of event-based programming with reactive objects. It discusses the traditional view of I/O and explains why today's environment doesn't facilitate it well. It also provides insights into implementing event-based programming with threads and reactive objects, using examples from Timber programming language.

browngloria
Download Presentation

Threads, Events, and Reactive Objects

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. Threads, Events, and Reactive Objects - Alan West CS533 - Concepts of Operating Systems

  2. Overview • Threads… Bad Idea • Traditional view of I/0 and why today’s environment doesn’t facilitate it well • Event-based programming model • Implemented with threads • Implemented with reactive object • Example: Reactive Objects in Timber CS533 - Concepts of Operating Systems

  3. Threads… Bad Idea • Threads used for: • Operating systems - one thread per process • Scientific Applications - one thread per CPU • Distributed Systems - process requests concurrently • GUIs - window events, mouse clicks, key clicks • Overkill for distributed systems and GUIs when true concurrency is not usually needed • Hard to program • Synchronization of shared data • Risk of deadlock CS533 - Concepts of Operating Systems

  4. Threads… Bad Idea cont. • Hard to debug • Timing dependencies • Performance degrades • Remember last class? Locks = significant overhead • Support for threads poor • Low portability • Thread-safe? • Few debugging tools. Remember Eraser? CS533 - Concepts of Operating Systems

  5. Solution: Event-based programming • True concurrency not need in many cases… So, use event based programming • One stream of execution • Event loop waits for events and invokes handlers • No preemption of event handlers • Handlers generally short-lived • Good for GUI’s and distributed systems • One handler for each GUI event or source of input CS533 - Concepts of Operating Systems

  6. Now let’s talk I/0: The traditional view • Assumption that environment is centrally controlled and synchronous • Transparent blocking • Interactions with environment through blocking subroutine calls • Batch-oriented CS533 - Concepts of Operating Systems

  7. Today’s environment is complex • GUI’s • Distributed networks • Multiple threads of execution • Environment is not centrally controlled • Asynchronous events occur at random CS533 - Concepts of Operating Systems

  8. Implement events with threads? • Each event (or types of events) could be handled by one threads. • Example: Mouse/Key clicks handled by one thread and monitoring a network socket with another thread. • Usage of threads conforms well to the traditional view of I/O • Each thread simply conforms to batch-oriented I/O CS533 - Concepts of Operating Systems

  9. Problems with using threads to implement events • Threads are hard (as mentioned before) • Threads used for events is not what threads were designed for • Events do not generally imply the need for concurrent execution. So, separate threads per event instead achieve concurrent blocking. • Threads are simply being used to circumvent an “inappropriate I/O model”. • Threads are harmful to the responsiveness of the program. A thread handling a certain event could potentially block and lead to missed events. • “Heavy encodings needed to turn even simple event-driven models into working code is most unfortunate” CS533 - Concepts of Operating Systems

  10. Reactive Objects • Takes an object-oriented approach to handling events • Provides a single object that is capable of handling all the various events a program is required to handle (e.g. mouse clicks, network packets) • Input: Environment calls a method of a program object. Input is a reaction. • Output: Program calls a method of an environment object. Output is a concrete act of the program. CS533 - Concepts of Operating Systems

  11. Reactive Objects cont. • A reactive object is capable of executing the sequential code of exactly one method at a time. • This ensures the integrity of data. Hence, gaining the benefits of a critical region. • Asynchronous vs. Synchronous method invocations • Send and forget w/ asynchronous. Sender and receiver continues executing in parallel. • Sender/receiver performs a rendezvous • Important restriction in reactive objects is that no methods must block execution indefinitely. CS533 - Concepts of Operating Systems

  12. Reactive Objects cont. • No continuous thread of execution • Methods guaranteed to terminate given deadlock is not encountered. However, deadlock can occur but only in a cyclic chain of synchronous method calls which is can be easily debugged. • Given that blocking methods are prohibited, responsiveness thrives. CS533 - Concepts of Operating Systems

  13. Reactive Objects vs. Monitors • Key difference is that concurrency in reactive objects is that only one method can be called at a time within a reactive object. • Monitors include calls that block (e.g. waiting on a condition). • Both provide encapsulation of shared data. CS533 - Concepts of Operating Systems

  14. Reactive Objects in Timber • Timber is a strongly typed, object oriented language that inherits much of its design from O’Haskell. • Ping: An example of reactive objects • Demonstrates how to concurrently measure the time it takes to connect to a number of remote hosts. • Sample output: • dogbert: 20.018 ms ratbert: 41.432 ms ratburg: NetError “lookup failure” theboss: no response • All methods in Ping are asynchronous. • Objects of Ping maintain the “outstanding” state variable which is a list of hosts CS533 - Concepts of Operating Systems

  15. Ping • Things to note: • inet.tcp.open initiates TCP connection • No where does this code block • Program does not wait for connection to be established ping hosts port env = template outstanding := hosts in let client host start peer = record connect = action env.putStrLn(host++": "++show(baseline-start)) outstanding := remove host outstanding peer.close neterror err = action env.putStrLn(host++": "++show err) outstanding := remove host outstanding deliver pkt = action done close = action done cleanup = action forall h <- outstanding do env.putStrLn(h++": no response") env.quit in record main = action forall h <- hosts do env.inet.tcp.open h port (client h baseline) after (2*seconds) CS533 - Concepts of Operating Systems

  16. Conclusions • Reactive objects provide simple/natural model of event driven systems. • Contains encapsulated state and provides the benefits of a critical region. • Threads are hard to program with and should only be used when concurrent execution is truly needed. • Therefore, reactive objects are a better solution for event driven systems. CS533 - Concepts of Operating Systems

More Related