%
%  $Id: reactor.tex,v 1.2 2005/04/29 15:16:41 gokhale Exp $
%
\section{Overview of Event Demultiplexing Patterns}
\label{sec:event_patterns}

This section describes the event demultiplexing patterns found in 
real-world systems that are used for ubiquitous computing, such as wireless
handhelds that support number of applications like email, calendar,
web browsing and multimedia. Section~\ref{sec:handheld} provides at a
typical event demultiplexing software architecture in handhelds.
Section~\ref{sec:reactor} then presents an outline of the reactor
pattern~\cite{Schmidt:00a} found in many real-world event driven
systems including the handhelds.

\subsection{Event-Driven Software Architecture in Mobile Handhelds}
\label{sec:handheld}

Figure~\ref{fig:handheld-arch} illustrates a typical software
architecture for event demultiplexing and dispatching in mobile
handhelds. Handhelds, such as PDAs, have been at the forefront of
ubiquitous computing and are getting increasingly complex due to 
the need to support to multiple applications, such as email, 
web browsing, calendar management, multimedia support, and games.  
Since these handhelds are used in many critical domains such as 
patient healthcare monitoring and emergency response systems, reliable
and efficient operation of these handhelds is esssential. Further,
since the software residing in these handhelds is primarily 
responsible for providing the necessary functionality, it is necessary
to analyze the software applications for their performance and 
reliability characteristics. In particular, in this paper we 
describe a methodology for the performability analysis of 
such event-driven software applications, which are commonly
used in ubiquitous computing. 
% folks, need citations - ASG

\begin{figure}[!h]
\center{\includegraphics[width=3.2in]{eps/handheld-demux.eps}}
\bfcaption{Event Demultiplexing in Handhelds}
\label{fig:handheld-arch}
\end{figure}

The application mix available in the handhelds is aptly suited for
event-driven systems, which requires demultiplexing and dispatching
events to the correct event handlers in the handheld.  For example,
a user of the handheld could have set appointments in his/her
calendar, which might raise an event while the user may be in the
midst of web browsing. Similarly it is conceivable that email
notification arrives while the user is in the midst of other
applications like web browsing or listening to audio.  In the context
of handhelds that are tailored to provide service to emergency
response personnel, one could conceive of a scenarios where sensor
data from a phenomenon of interest is received by the handheld with
other notifications, such as SMS notifications from the command and
control, received by the handheld. 

\iffalse
It is the responsibility of the software architecture to handle all
the events reliably.  Although it is possible to prioritize services
over one another, and also have more complex software support
including multiple thread support, we have focussed on a simpler
single threaded event handling mechanism.  We are not aware of any
prior work on performability modeling in the context of ubiquitous
computing.  Thus, our first set of results described performability
analysis for single threaded event handling frameworks.
Section~\ref{} then describes our tool support to build complex
performability models.
\fi
% folks, I give a hint of the tool driven approach here.- ASG
% Aniruddha, we do not want to say that these are the first results. 
% Also, making the case that these are parts of emergency response 
% systems, and then further saying that we are doing non-deterministic
% handling does not gel well. 
% Also, the word "reliable" appears many times. I don't think we have to
% keep using that word again and again. Actually, I would be comfortable
% leaving the above paragraph out. We are once again dropping clues as
% to why our work is preliminary here.
%  
% TODO

\subsection{Description of the Reactor Pattern}
\label{sec:reactor}

Event demultiplexing, dispatching and event handling is a hallmark of
event-driven systems exemplified by the application mix in handhelds.
The development of these systems is increasingly relying on
the use of well-documented patterns~\cite{Vlissides:94,Schmidt:00a},
The use of patterns offers the potential of improving the reliability
as well as enabling faster time-to-market by fostering reuse.
Fundamental to the design and development of
event-driven systems is the Reactor pattern~\cite{Schmidt:00a}.
Therefore, performability analysis of the event-driven aspects of
systems, such as the handhelds, boils down to the performability
analysis of the reactor pattern.  This section therefore provides
background information on the reactor pattern and its dynamics.

Figure~\ref{fig:mw-demux} depicts a typical event demultiplexing and
dispatching mechanism documented in the reactor
pattern~\cite{Schmidt:00a}.  The 
application registers an event handler with the event demultiplexer
and delegates to it the responsibility of listening to incoming
events. On the occurrence of an event, the demultiplexer dispatches the
event by making a callback to the correct application-supplied event
handler. This is the idea behind the reactor pattern, which provides
synchronous event demultiplexing and dispatching capabilities.

\begin{figure}[htb]
\begin{center}
\includegraphics[width=2.3in]{../Sigmetrics-2005/eps/demux.eps}
\bfcaption{Event Demultiplexing Pattern}
\label{fig:mw-demux}
\end{center}
\end{figure}

Figure~\ref{fig:reactor_dynamics} illustrates the reactor pattern
dynamics. We categorize these dynamics into two phases described below.

\begin{enumerate}
  \item {\bf Registration phase:} In this phase all the event handlers
  register with the reactor associating themselves with a particular
  event type they are interested in.  Event types usually supported by
  a reactor are input, output, timeout and exceptions.  The reactor
  will maintain a set of handles corresponding to each handler
  registered with it.
  \item {\bf Snapshot phase:} Once the event handlers have completed
  their registration, the main thread of control is passed to the
  reactor, which in turn listens for events to occur. A snapshot is
  then an instance in time wherein a reactor determines all the event
  handles that are enabled at that instant.  For all the event handles
  that are enabled in a given snapshot, the reactor proceeds to
  service each event by invoking the associated event handler.  There
  could be different strategies to handle these events. For example, a reactor
  could handle all the enabled events sequentially in a single thread
  or could hand it over to worker threads in a thread pool. After all
  the events are processed, the reactor proceeds to take the next
  snapshot of the system.
\end{enumerate}

\begin{figure}[htb]
\begin{center}
\includegraphics[width=3.3in]{eps/reactor_dynamics.eps}
\bfcaption{Reactor Pattern Dynamics}
\label{fig:reactor_dynamics}
\end{center}
\end{figure}

Many different variations of the reactor pattern are possible. These
variations stem from the different event demultiplexing and event
handling strategies used in a reactor. For example, in
network-centric applications, networking events can
be demultiplexed using operating system calls, such as {\tt select} or
{\tt poll}.  For graphical user interfaces (GUIs), these events could
be due primarily to mouse clicks and can be handled by GUI
frameworks like Qt or Tk. On the other hand, the event handling
mechanisms could involve a single thread of control that demultiplexes
and handles an event, or each event could be handled concurrently using
worker threads in a thread pool or by thread on demand.

In this paper, we have developed a performability model of 
the reactor pattern, which uses the {\tt select} system call for event
demultiplexing and uses a single thread of control to demultiplex and
handle events identified in a given snapshot. In the rest of the paper
we describe this model and demonstrate the use of the model for
performability analysis. 
