CS533 - Concepts of Operating Systems 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 o Implemented with threads o Implemented with reactive object  Example: Reactive Objects in Timber

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

CS533 - Concepts of Operating Systems 4 Threads… Bad Idea cont.  Hard to debug o Timing dependencies  Performance degrades o Remember last class? Locks = significant overhead  Support for threads poor o Low portability o Thread-safe? o 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 o 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 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 o 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 o Send and forget w/ asynchronous. Sender and receiver continues executing in parallel. o 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 o Demonstrates how to concurrently measure the time it takes to connect to a number of remote hosts.  Sample output: o dogbert: ms ratbert: 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 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) Things to note:  inet.tcp.open initiates TCP connection  No where does this code block  Program does not wait for connection to be established

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.