changes
authorPeizhao Ou <peizhaoo@uci.edu>
Fri, 10 Apr 2015 18:02:05 +0000 (11:02 -0700)
committerPeizhao Ou <peizhaoo@uci.edu>
Fri, 10 Apr 2015 18:02:05 +0000 (11:02 -0700)
78 files changed:
correctness-model/note.txt [new file with mode: 0644]
correctness-model/writeup/.#implementation.tex.1.9 [new file with mode: 0644]
correctness-model/writeup/.#introduction.tex.1.24 [new file with mode: 0644]
correctness-model/writeup/.#introduction.tex.1.26 [new file with mode: 0644]
correctness-model/writeup/.#memorymodel.tex.1.1 [new file with mode: 0644]
correctness-model/writeup/.#specification.tex.1.47 [new file with mode: 0644]
correctness-model/writeup/CVS/Entries [new file with mode: 0644]
correctness-model/writeup/CVS/Repository [new file with mode: 0644]
correctness-model/writeup/CVS/Root [new file with mode: 0644]
correctness-model/writeup/abstract.tex [new file with mode: 0644]
correctness-model/writeup/conclusion.tex [new file with mode: 0644]
correctness-model/writeup/confstrs-abbrv.bib [new file with mode: 0644]
correctness-model/writeup/confstrs-long.bib [new file with mode: 0644]
correctness-model/writeup/evaluation.tex [new file with mode: 0644]
correctness-model/writeup/example.tex [new file with mode: 0644]
correctness-model/writeup/figures/CVS/Entries [new file with mode: 0644]
correctness-model/writeup/figures/CVS/Repository [new file with mode: 0644]
correctness-model/writeup/figures/CVS/Root [new file with mode: 0644]
correctness-model/writeup/figures/fence_sw.dot [new file with mode: 0644]
correctness-model/writeup/figures/fence_sw2.dot [new file with mode: 0644]
correctness-model/writeup/figures/fence_sw_r_collapse.dot [new file with mode: 0644]
correctness-model/writeup/figures/fence_sw_r_collapse2.dot [new file with mode: 0644]
correctness-model/writeup/figures/fence_sw_w_collapse.dot [new file with mode: 0644]
correctness-model/writeup/figures/fence_sw_w_collapse2.dot [new file with mode: 0644]
correctness-model/writeup/figures/ff_sc_rf.dot [new file with mode: 0644]
correctness-model/writeup/figures/ff_sc_rf2.dot [new file with mode: 0644]
correctness-model/writeup/figures/fw_sc_rf.dot [new file with mode: 0644]
correctness-model/writeup/figures/fw_sc_rf2.dot [new file with mode: 0644]
correctness-model/writeup/figures/lockhistory.pdf [new file with mode: 0644]
correctness-model/writeup/figures/rcuhistory.odg [new file with mode: 0644]
correctness-model/writeup/figures/rcuhistory.pdf [new file with mode: 0644]
correctness-model/writeup/figures/release_seq.pdf [new file with mode: 0644]
correctness-model/writeup/figures/rmw_atomicity.dot [new file with mode: 0644]
correctness-model/writeup/figures/rmw_atomicity2.dot [new file with mode: 0644]
correctness-model/writeup/figures/rmw_mo.dot [new file with mode: 0644]
correctness-model/writeup/figures/rmw_mo2.dot [new file with mode: 0644]
correctness-model/writeup/figures/rr_mo.dot [new file with mode: 0644]
correctness-model/writeup/figures/rr_mo2.dot [new file with mode: 0644]
correctness-model/writeup/figures/rw_mo.dot [new file with mode: 0644]
correctness-model/writeup/figures/rw_mo2.dot [new file with mode: 0644]
correctness-model/writeup/figures/sc_mo.dot [new file with mode: 0644]
correctness-model/writeup/figures/sc_mo2.dot [new file with mode: 0644]
correctness-model/writeup/figures/sc_wr_mo.dot [new file with mode: 0644]
correctness-model/writeup/figures/sc_wr_mo2.dot [new file with mode: 0644]
correctness-model/writeup/figures/specdesign.pdf [new file with mode: 0644]
correctness-model/writeup/figures/specworkflow.pdf [new file with mode: 0644]
correctness-model/writeup/figures/wf_sc_rf.dot [new file with mode: 0644]
correctness-model/writeup/figures/wf_sc_rf2.dot [new file with mode: 0644]
correctness-model/writeup/figures/workflow.pdf [new file with mode: 0644]
correctness-model/writeup/figures/wr_mo.dot [new file with mode: 0644]
correctness-model/writeup/figures/wr_mo2.dot [new file with mode: 0644]
correctness-model/writeup/figures/ww_mo.dot [new file with mode: 0644]
correctness-model/writeup/figures/ww_mo2.dot [new file with mode: 0644]
correctness-model/writeup/figures/ww_sc_fence_first_collapse.dot [new file with mode: 0644]
correctness-model/writeup/figures/ww_sc_fence_first_collapse2.dot [new file with mode: 0644]
correctness-model/writeup/figures/ww_sc_fence_mo.dot [new file with mode: 0644]
correctness-model/writeup/figures/ww_sc_fence_mo2.dot [new file with mode: 0644]
correctness-model/writeup/figures/ww_sc_fence_second_collapse.dot [new file with mode: 0644]
correctness-model/writeup/figures/ww_sc_fence_second_collapse2.dot [new file with mode: 0644]
correctness-model/writeup/formalization.tex [new file with mode: 0644]
correctness-model/writeup/implementation.tex [new file with mode: 0644]
correctness-model/writeup/introduction.tex [new file with mode: 0644]
correctness-model/writeup/issta15_submission.pdf [new file with mode: 0644]
correctness-model/writeup/makefile [new file with mode: 0644]
correctness-model/writeup/memorymodel.tex [new file with mode: 0644]
correctness-model/writeup/paper.aux [new file with mode: 0644]
correctness-model/writeup/paper.bbl [new file with mode: 0644]
correctness-model/writeup/paper.bib [new file with mode: 0644]
correctness-model/writeup/paper.blg [new file with mode: 0644]
correctness-model/writeup/paper.log [new file with mode: 0644]
correctness-model/writeup/paper.pdf [new file with mode: 0644]
correctness-model/writeup/paper.tex [new file with mode: 0644]
correctness-model/writeup/related.tex [new file with mode: 0644]
correctness-model/writeup/sig-alternate.cls [new file with mode: 0644]
correctness-model/writeup/speccfg.tex [new file with mode: 0644]
correctness-model/writeup/specification.tex [new file with mode: 0644]
correctness-model/writeup/spell.lst [new file with mode: 0644]
correctness-model/writeup/technical.tex [new file with mode: 0644]

diff --git a/correctness-model/note.txt b/correctness-model/note.txt
new file mode 100644 (file)
index 0000000..e69de29
diff --git a/correctness-model/writeup/.#implementation.tex.1.9 b/correctness-model/writeup/.#implementation.tex.1.9
new file mode 100644 (file)
index 0000000..a741b61
--- /dev/null
@@ -0,0 +1,163 @@
+\mysection{Implementation}\label{sec:implementation}
+
+The goal of the \TOOL specification language is to
+enable developers to write specifications against which concurrent data structures can be tested.
+We can ensure a concurrent data structure is correct with
+respect to an equivalent sequential data structure if for each
+execution of the concurrent data structure, the equivalent sequential
+history for the equivalent sequential data structure yields the same
+results.
+
+The execution space for many concurrent data
+structures is unbounded, meaning that in practice we cannot 
+verify correctness by checking individual executions. However, the
+specifications can be used for unit testing.  In practice,
+many bugs can be exposed by model checking unit tests for 
+concurrent data structures.  We have implemented the \TOOL checker as a
+unit testing tool built upon the \cdschecker framework.  The \TOOL checker
+can exhaustively explore all behaviors for unit tests and provide
+developers with diagnostic reports for executions that violate their
+specification.
+
+
+\mysubsection{Model Checker Framework}
+
+The \TOOL checker takes as input a complete execution trace from the
+\cdschecker model checker. The \cdschecker framework operates at the abstraction level of
+individual atomic operations and thus has neither information about method
+calls nor which atomic operations serve as ordering points.  Thus, we
+extend the framework by adding {\it annotation} operations to
+\cdschecker's traces, which record the necessary information to check the specifications
+but have no effect on other operations.  The \TOOL compiler
+inserts code to generate the annotation actions to communicate to the \TOOL checker
+plugin the critical events for checking the \TOOL specification.
+These annotation actions then appear in \cdschecker's list of atomic
+operations and make it convenient for  \TOOL to construct
+a sequential history from the execution because for any given method
+call, its invocation event, its ordering points, and its response event are
+sequentially ordered in the list. 
+
+\mysubsection{Specification Compiler}
+
+The specification compiler translates an annotated
+C/C++ program into an instrumented C/C++ program that will generate
+execution traces containing the dynamic information needed to check
+assertions and construct the sequential history.  We next
+describe the type of annotation actions that the \TOOL compiler
+inserts into the instrumented program.
+
+\mypara{\bf Ordering Points:} Ordering points have a conditional guard expression
+and a label. Potential ordering point annotation actions are 
+inserted immediately after the atomic operation that serves as 
+the potential ordering point.  Ordering point check annotation actions are
+inserted where they appear.
+
+\mypara{\bf Method Boundary:} To identify a method's boundaries, \TOOL
+inserts {\it method\_begin} and {\it method\_end} annotations at the
+beginning and end of methods.
+
+\mypara{\bf Sequential States and Methods:} Since checking occurs
+after \cdschecker has completed an execution, the annotation
+actions stores the values of any variables in the concurrent data
+structure that the annotations reference.
+
+\mypara{\bf Side Effects and Assertions:} Side effects and assertions perform
+their checks after an execution.  The side effects and assertions are compiled
+into methods and the equivalent sequential data structure's states are accessible to these methods.
+With this encapsulation,
+the \TOOL checker simply calls these functions to implement the side effects and assertions.
+
+\mypara{\bf Synchronization Checks:} The \TOOL checker performs
+synchronization checks in two parts: compiling the rules and runtime data
+collection.  First, the \TOOL compiler numbers all methods and happens-before
+checks uniquely. For example, the rule ``\code{Update->Read}'' can be represented as (1, 0, 2, 0),
+which means instances of method 1 that satisfy condition 0 should {\it
+  synchronize with} instances method 2 that satisfy condition 0. In this case,
+  condition 0 means \code{true}. Then,
+the \TOOL compiler generates code that communicates the
+synchronization rules by passing an array of integer pairs.  Runtime
+collection is then implemented by performing the condition check at
+each method invocation or response and then passing the method number
+and happens before condition if the check is satisfied.
+
+\mysubsection{Dynamic Checking}
+
+At this point, we have an execution trace with the necessary
+annotations to construct a sequential history and to check
+the execution's correctness.  However, before constructing the
+sequential history, the \TOOL plugin first collects
+the necessary information for each method call, which is the {\it
+  method\_begin} annotation, the ordering point annotations, the
+happens-before checks, and the {\it method\_end} annotations.  Since
+all of the operations in the trace have thread
+identifiers it is straightforward to extract the operations between the {\it
+  method\_begin} and {\it method\_end} annotations.  
+
+\mypara{\bf Reorder Method Calls:} As discussed above, determining the
+ordering of the ordering points is non-trivial under the
+C/C++ memory model. This can be complicated by the fact
+that the C/C++ memory model allows atomic loads to read from atomic
+stores that appear later in the trace and that we do not maintain program order in our
+correctness model.
+
+However, we can still leverage the reads-from relation and the modification-order
+relation to order the ordering points that appear in typical data
+structures.  \TOOL uses the following rules to generate an ordering-point
+ordering $\reltext{opo}$ relation on ordering points. Given two operations $X$ and $Y$ that are both ordering points:
+
+\begin{enumerate}
+\item {\bf Reads-From:} $X \xrightarrow{rf} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (write-write):} $X \xrightarrow{mo} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (read-write):} $A \xrightarrow{mo} Y \ \wedge \  A \xrightarrow{rf} X \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (write-read):} $X \xrightarrow{mo} B \ \wedge \  B \xrightarrow{rf} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (read-read):} $A \xrightarrow{mo} B \ \wedge \  A \xrightarrow{rf} X \ \wedge \  B \xrightarrow{rf} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\end{enumerate}
+
+\mypara{\bf Generating the Reordering:}
+The \TOOL checker first builds an execution graph where the nodes are
+method calls and the edges represent the
+$\reltext{opo}$ ordering of the ordering points of the methods that
+correspond to the source and destination nodes.  Assuming the absence
+of cycles in the execution graph, 
+the $\reltext{opo}$ ordering is used to generate the sequential history.
+If two methods are not ordered by the
+$\reltext{opo}$ order, we assume that they commute and select an
+arbitrary ordering for the methods.  The \TOOL checker 
+topologically sorts the graph to generate the equivalent sequential
+execution. 
+
+When \TOOL fails to order ordering points, the operations often commute. Thus,
+if multiple histories satisfy the constraints of \reltext{opo}, we generally
+pick a random one for most data structures. However, when those operations
+do not commute, we provide developers with different options: (1) they can
+add additional ordering points to allow \TOOL to order the two nodes or
+(2) they run \TOOL in either of the following modes: (a) \textit{loosely
+exhaustive} mode --- \TOOL explores
+all possible histories and only requires some history to be correct or
+(b) \textit{strictly exhaustive} mode --- \TOOL explores all possible histories and requires all histories to
+be correct. With these options, developers are able to balance the
+tradeoff between specifying more ordering points and the searching
+space. For example, for a single producer single
+consumer queue based on a linked-list (maintaing \code{head} and \code{tail} pointer), if we only
+specify the update and load of the next field of a linked-list node as ordering points for
+\code{enqueue} and \code{dequeue}, \TOOL will fail to order a dequeue
+returning \code{NULL} and another enqueue because dequeue does not have the
+ordering point of loading the next field. In this case, developers can either
+add extra ordering points to order the dequeue before the enqueue or simply run it in the
+\textit{loosely exhaustive} mode and that mode will produce at least one correct
+history.
+
+\mypara{\bf Check Synchronization Properties:} Synchronization properties are
+specified using the IDs and conditions of method calls, and we have that information
+ready after \TOOL constructs the sequential history and checks the preconditions
+and postconditions. For two specific method calls $c_1$ and $c_2$, we can ensure
+$c_1$ synchronizes with $c_2$ by ensuring the annotation \code{c1\_begin}
+happens-before the annotation \code{c2\_end} because any operations
+sequenced-before \code{c1\_begin} should happen-before any operations
+sequenced-after \code{c2\_end} according to the C/C++11 memory model.
+
diff --git a/correctness-model/writeup/.#introduction.tex.1.24 b/correctness-model/writeup/.#introduction.tex.1.24
new file mode 100644 (file)
index 0000000..02c4ff7
--- /dev/null
@@ -0,0 +1,222 @@
+\mysection{Introduction}\label{sec:introduction}
+
+Concurrent data structure design can improve scalability by supporting
+multiple simultaneous operations, reducing memory coherence traffic, and reducing the time taken by an
+individual data structure operation.  Researchers have developed many concurrent
+data structure designs with these goals~\cite{rcu,
+lockfreequeue}.  Concurrent data structures often use sophisticated techniques
+including low-level atomic instructions (e.g., compare and
+swap), careful reasoning about the order of loads and
+stores, and fine-grained locking.    For example, while the standard Java hash
+table implementation can limit scalability to a handful of cores,
+more sophisticated concurrent hash tables can scale to many hundreds of
+cores~\cite{javaConcurrentHashMap}.  
+
+The C/C++ standard committee extended the C and C++ languages with
+support for low-level atomic operations in the C/C++11
+standard~\cite{cpp11spec, c11spec, boehmpldi} to enable developers to
+write portable implementations of concurrent data structures.  To support the relaxations typically performed by compilers and processors, 
+the
+C/C++ memory model provides weaker semantics than sequential
+consistency~\cite{scmemorymodel} and as a result, correctly using
+these operations is challenging.  Developers must not only
+reason about potential interleavings, but also about how the processor
+and compiler might reorder memory operations.  Even experts make
+subtle errors when reasoning about such memory models.
+
+Researchers have developed tools for exploring the behavior of code
+under the C/C++ model including \cdschecker~\cite{cdschecker}, {\sc
+Cppmem}~\cite{c11popl}, and Relacy~\cite{relacy}.  These tools explore
+behaviors that are allowed under the C/C++ memory model.  While these
+tools can certainly be useful for exploring executions, they can be
+challenging to use for testing as they don't provide support (other
+than assertions) for specifying the behavior of data structures.
+Using assertions can be challenging as different interleavings or
+reorderings legitimately produce different behaviors, and it can be
+very difficult to code assertions to check the output of a test case under for an
+arbitrary (unknown) execution.
+
+This paper presents \TOOL, a specification language and specification
+checking tool that is designed to be used in conjunction with model
+checking tools.  We have implemented it as a plugin for
+the \cdschecker model checker.
+
+\mysubsection{Background on Linearizability}
+
+Researchers have developed several techniques for specifying
+correctness properties of concurrent data structures written for strong memory
+models.  While these techniques cannot handle the behaviors typically
+exhibited by relaxed data structure implementations, they provide insight into
+intuitive approaches to specifying concurrent data structure behavior.
+
+One approach for specifying the correctness of concurrent data
+structures is in terms of equivalent sequential executions of either
+the concurrent data structure or a simplified sequential version.  The
+problem then becomes how do we map a concurrent execution to an equivalent
+sequential execution?  A common criterion is {\it
+  linearizability} --- linearizability simply states that a concurrent
+operation can be viewed as taking effect at some time between its
+invocation and its return (or response)~\cite{linearizableref}.
+
+An {\it equivalent sequential data structure} is a sequential version
+of a concurrent data structure that can be used to express correctness
+properties by relating executions of the original concurrent data
+structure with executions of the equivalent sequential data structure.
+The equivalent sequential data structure is often simpler and can in
+many cases simply use existing well-tested implementations in the
+STL library.
+
+An execution {\it history} is a total order of method invocations and
+responses. A {\it sequential history} is one where all invocations are
+followed by the corresponding responses immediately. A concurrent
+execution is correct if its behavior is consistent with its equivalent
+sequential history replayed on the equivalent sequential data
+structure. A concurrent object is linearizable if for all executions:
+\begin{enumerate}
+\item Each method call appears to take effect instantaneously at some
+  point between its invocation and response.
+
+\item The invocations and responses can be reordered to yield a
+  sequential history under the rule that an invocation cannot be
+  reordered before the preceding responses.
+
+\item The concurrent execution yields the same behavior as
+  the sequential history.
+\end{enumerate}
+
+A weaker variation of linearization is {\it sequential
+consistency}\footnote{It is important to note that the term sequential
+consistency in the literature is applied to both the consistency model
+that data structures expose clients to as well as the guarantees that
+the underlying memory system provides for load and store operations.}.
+Sequential consistency only requires that there exist a sequential
+history that is consistent with the {\it program order} (the intra-thread
+order).  This ordering does not need to be consistent with the order
+that the operations were actually issued in.
+
+Line-Up~\cite{lineup}, Paraglider~\cite{VechevMCLinear}, and
+VYRD~\cite{vyrd} that leverage linearizability to test concurrent data
+structures.  {\bf Unfortunately, efficient implementations of many
+common data structures, e.g., RCU~\cite{rcu}, MS
+Queue~\cite{lockfreequeue}, ..., for the C/C++ memory model are
+neither linearizable nor sequentially consistent! Thus previous tools
+cannot check such data structures under the C/C++ memory model.}
+
+\mysubsection{New Challenges from the C/C++ Memory Model}
+\label{sec:introNewChallenges}
+
+The C/C++ memory model brings the following two key challenges that prevent the application of previous approaches to checking concurrent data structures to this setting:
+
+\squishcount
+\item {\bf Relaxed Executions Break Existing Data Structure Consistency Models:}
+C/C++ data structures often expose clients to weaker (non-SC)
+behaviors to gain performance.  A common guarantee is to provide
+happens-before synchronization between operations that implement
+updates and the operations that read those updates.  These data
+structures often do not guarantee that different threads observe updates in the
+same order --- in other words the data structures may expose clients
+to weaker consistency models than sequential consistency.  For
+example, even when one uses the relatively strong \code{acquire}
+and \code{release} memory orderings in C++, it is possible for two
+different threads to observe two stores happening in
+different orders, i.e., executions can fail the IRIW test.
+Thus many data structure legitimately admit executions for which there
+are no sequential histories that preserve program order.
+
+Like many other relaxed memory models, the C/C++ memory model does
+not include a total order over all memory operations, thus even
+further complicating the application of traditional approaches to correctness,
+e.g., linearization cannot be applied.  In
+particular the approaches that relate the behaviors of concurrent data
+structures to analogous sequential data structures break down due to
+the absence of a total ordering of the memory operations.  While many
+of the dynamic tools~\cite{cdschecker,relacy} for exploring the
+behavior of code under relaxed models do as a practical matter
+print out an execution in some order, this order is to some degree arbitrary as relaxed memory models
+generally make it possible for a data structure operation to see the
+effects of operations that appear later in any such an order (e.g., a load
+can read from a store that appears later in the order).  Instead of a total order, the C/C++
+memory model is formulated as a graph of memory operations
+with several partial orders defined in this graph.
+
+\item {\bf Constraining Reorderings (Specifying Synchronization Properties):}
+Synchronization\footnote{Synchronization here is not mutual exclusion,
+  but rather a lower-level property that captures which stores must be
+  visible to a thread.  In other words, it constrains which
+  reorderings can be performed by a processor or compiler.} in C/C++
+  provides an ordering between memory operations to different
+  locations.  Concurrent data structures must establish
+  synchronization or they potentially expose their users to highly
+  non-intuitive behavior that is likely to break client code.  For
+  example, consider the case of a concurrent queue that does not
+  establish synchronization between enqueue and dequeue operations.
+  If one thread initializes the fields of an object and then enqueues
+  a reference to that object in such a queue and a second thread
+  dequeues the reference and uses it to read the fields of that
+  object, the second thread could fail to see the initializing writes.
+  This surprising behavior could occur if the compiler or CPU could
+  reorder the initializing writes to be executed after the enqueue
+  operation.  If the fields are non-atomic, such loads are considered
+  data races and violate the data race free requirement of the C/C++
+  language standard and thus the program has no semantics.
+
+The C/C++ memory model formalizes synchronization in terms of a {\it
+  happens-before} relation.  The C/C++ happens-before relationship
+is a partial order over memory accesses.  If memory access {\it x}
+happens before memory access {\it y}, it means that the effects of
+{\it x} must be ordered before  the effects of {\it y}. 
+\countend
+
+\begin{figure}
+        \centering
+\vspace{-.3cm}
+       \includegraphics[scale=0.35]{figures/specworkflow}
+\vspace{-.4cm}
+               \caption{\label{fig:specworkflow} \TOOL system overview}
+\vspace{-.4cm}
+\end{figure}
+
+\mysubsection{Specification Language and Tool Support}
+
+Figure~\ref{fig:specworkflow} presents an overview of the \TOOL system. After
+implementing a concurrent data structure, developers annotate their code
+with a \TOOL specification. To test their implementation,
+developers compile the data structure with the \TOOL specification
+compiler to extract the specification and generate a program that is instrumented with specification checks.
+ Then, developers compile the instrumented program with a
+standard C/C++ compiler. Finally, developers run the binary under 
+the \TOOL checker. \TOOL
+then exhaustively explores the behaviors of the specific unit test and
+generates diagnostic reports for any executions that violate the specification.
+
+\mysubsection{Contributions}
+
+This paper makes the following contributions:
+
+\begin{itemize}
+\item {\bf Specification Language:} It introduces a specification
+  language that enables developers to write specifications of
+  concurrent data structures developed for a relaxed memory model in a
+  simple fashion that captures the key correctness properties.  Our
+  specification language is the first to our knowledge that supports concurrent data
+  structures that use C/C++ atomic operations.
+
+\item {\bf A Technique to Relate Concurrent Executions to Sequential Executions:}  It presents an approach to order the memory operations for the
+  C/C++ model, which lacks a definition of a trace and for which one
+  generally cannot even construct a total order of atomic operations
+  that is consistent with the program order.  The generated
+  sequential execution by necessity does not always maintain program order.
+  
+\item {\bf Synchronization Properties:} It presents constructs
+  for specifying the happens before relations that a data structure
+  should establish and tool support for checking these properties and
+  exposing synchronization related bugs.
+
+\item {\bf Tool for Checking C/C++ Data Structures Against Specifications:} \TOOL is the first tool to our knowledge that can check concurrent data structures that exhibit relaxed behaviors against specifications that are specified in terms intuitive sequential executions.
+
+\item {\bf Evaluation:} It shows that the \TOOL specification language can express key correctness properties for a
+set of real-world concurrent data structures, that our tool can detect
+  bugs, and that our tool can unit test real world data structures
+  with reasonable performance.
+\end{itemize}
+
diff --git a/correctness-model/writeup/.#introduction.tex.1.26 b/correctness-model/writeup/.#introduction.tex.1.26
new file mode 100644 (file)
index 0000000..33c8499
--- /dev/null
@@ -0,0 +1,223 @@
+\mysection{Introduction}\label{sec:introduction}
+
+Concurrent data structure design can improve scalability by supporting
+multiple simultaneous operations, reducing memory coherence traffic, and reducing the time taken by an
+individual data structure operation.  Researchers have developed many concurrent
+data structure designs with these goals~\cite{rcu,
+lockfreequeue}.  Concurrent data structures often use sophisticated techniques
+including low-level atomic instructions (e.g., compare and
+swap), careful reasoning about the order of loads and
+stores, and fine-grained locking.    For example, while the standard Java hash
+table implementation can limit scalability to a handful of cores,
+more sophisticated concurrent hash tables can scale to many hundreds of
+cores~\cite{javaConcurrentHashMap}.  
+
+The C/C++ standard committee extended the C and C++ languages with
+support for low-level atomic operations in the C/C++11
+standard~\cite{cpp11spec, c11spec, boehmpldi} to enable developers to
+write portable implementations of concurrent data structures.  To support the relaxations typically performed by compilers and processors, 
+the
+C/C++ memory model provides weaker semantics than sequential
+consistency~\cite{scmemorymodel} and as a result, correctly using
+these operations is challenging.  Developers must not only
+reason about potential interleavings, but also about how the processor
+and compiler might reorder memory operations.  Even experts make
+subtle errors when reasoning about such memory models.
+
+Researchers have developed tools for exploring the behavior of code
+under the C/C++ model including \cdschecker~\cite{cdschecker}, {\sc
+Cppmem}~\cite{c11popl}, and Relacy~\cite{relacy}.  These tools explore
+behaviors that are allowed under the C/C++ memory model.  While these
+tools can certainly be useful for exploring executions, they can be
+challenging to use for testing as they don't provide support (other
+than assertions) for specifying the behavior of data structures.
+Using assertions can be challenging as different interleavings or
+reorderings legitimately produce different behaviors, and it can be
+very difficult to code assertions to check the output of a test case under for an
+arbitrary (unknown) execution.
+
+This paper presents \TOOL, a specification language and specification
+checking tool that is designed to be used in conjunction with model
+checking tools.  We have implemented it as a plugin for
+the \cdschecker model checker.
+
+\mysubsection{Background on Linearizability}
+
+Researchers have developed several techniques for specifying
+correctness properties of concurrent data structures written for strong memory
+models.  While these techniques cannot handle the behaviors typically
+exhibited by relaxed data structure implementations, they provide insight into
+intuitive approaches to specifying concurrent data structure behavior.
+
+One approach for specifying the correctness of concurrent data
+structures is in terms of equivalent sequential executions of either
+the concurrent data structure or a simplified sequential version.  The
+problem then becomes how do we map a concurrent execution to an equivalent
+sequential execution?  A common criterion is {\it
+  linearizability} --- linearizability simply states that a concurrent
+operation can be viewed as taking effect at some time between its
+invocation and its return (or response)~\cite{linearizableref}.
+
+An {\it equivalent sequential data structure} is a sequential version
+of a concurrent data structure that can be used to express correctness
+properties by relating executions of the original concurrent data
+structure with executions of the equivalent sequential data structure.
+The equivalent sequential data structure is often simpler, and in
+many cases one can simply use existing well-tested implementations from the
+STL library.
+
+An execution {\it history} is a total order of method invocations and
+responses. A {\it sequential history} is one where all invocations are
+followed by the corresponding responses immediately. A concurrent
+execution is correct if its behavior is consistent with its equivalent
+sequential history replayed on the equivalent sequential data
+structure. A concurrent object is linearizable if for all executions:
+\begin{enumerate}
+\item Each method call appears to take effect instantaneously at some
+  point between its invocation and response.
+
+\item The invocations and responses can be reordered to yield a
+  sequential history under the rule that an invocation cannot be
+  reordered before the preceding responses.
+
+\item The concurrent execution yields the same behavior as
+  the sequential history.
+\end{enumerate}
+
+A weaker variation of linearization is {\it sequential
+consistency}\footnote{It is important to note that the term sequential
+consistency in the literature is applied to both the consistency model
+that data structures expose clients to as well as the guarantees that
+the underlying memory system provides for load and store operations.}.
+Sequential consistency only requires that there exist a sequential
+history that is consistent with the {\it program order} (the intra-thread
+order).  This ordering does not need to be consistent with the order
+that the operations were actually issued in.
+
+Line-Up~\cite{lineup}, Paraglider~\cite{VechevMCLinear}, and
+VYRD~\cite{vyrd} leverage linearizability to test concurrent data
+structures.  {\bf Unfortunately, efficient implementations of many
+common data structures, e.g., RCU~\cite{rcu}, MS
+Queue~\cite{lockfreequeue}, ..., for the C/C++ memory model are
+neither linearizable nor sequentially consistent! Thus previous tools
+cannot check such data structures under the C/C++ memory model.}
+
+\mysubsection{New Challenges from the C/C++ Memory Model}
+\label{sec:introNewChallenges}
+
+The C/C++ memory model brings the following two key challenges that prevent the application of previous approaches to checking concurrent data structures to this setting:
+
+\squishcount
+\item {\bf Relaxed Executions Break Existing Data Structure Consistency Models:}
+C/C++ data structures often expose clients to weaker (non-SC)
+behaviors to gain performance.  A common guarantee is to provide
+happens-before synchronization between operations that implement
+updates and the operations that read those updates.  These data
+structures often do not guarantee that different threads observe updates in the
+same order --- in other words the data structures may expose clients
+to weaker consistency models than sequential consistency.  For
+example, even when one uses the relatively strong \code{acquire}
+and \code{release} memory orderings in C++, it is possible for two
+different threads to observe two stores happening in
+different orders, i.e., executions can fail the IRIW test.
+Thus many data structure legitimately admit executions for which there
+are no sequential histories that preserve program order.
+
+Like many other relaxed memory models, the C/C++ memory model does
+not include a total order over all memory operations, thus even
+further complicating the application of traditional approaches to correctness,
+e.g., linearization cannot be applied.  In
+particular the approaches that relate the behaviors of concurrent data
+structures to analogous sequential data structures break down due to
+the absence of a total ordering of the memory operations.  While many
+of the dynamic tools~\cite{cdschecker,relacy} for exploring the
+behavior of code under relaxed models do as a practical matter
+print out an execution in some order, this order is to some degree arbitrary as relaxed memory models
+generally make it possible for a data structure operation to see the
+effects of operations that appear later in any such an order (e.g., a load
+can read from a store that appears later in the order).  Instead of a total order, the C/C++
+memory model is formulated as a graph of memory operations
+with several partial orders defined in this graph.
+
+\item {\bf Constraining Reorderings (Specifying Synchronization Properties):}
+Synchronization\footnote{Synchronization here is not mutual exclusion,
+  but rather a lower-level property that captures which stores must be
+  visible to a thread.  In other words, it constrains which
+  reorderings can be performed by a processor or compiler.} in C/C++
+  provides an ordering between memory operations to different
+  locations.  Concurrent data structures must establish
+  synchronization or they potentially expose their users to highly
+  non-intuitive behavior that is likely to break client code.  For
+  example, consider the case of a concurrent queue that does not
+  establish synchronization between enqueue and dequeue operations. Consider the
+  following sequence of operations: (1) thread A initializes the fields of a new
+  object X; (2) thread A enqueues the reference to X in such a queue
+  (3) thread B dequeues the reference to X; (4) thread B reads the
+  fields of X through the dequeued reference. In (4), thread B could fail to see the
+  initializing writes from (1).
+  This surprising behavior could occur if the compiler or CPU could
+  reorder the initializing writes to be executed after the enqueue
+  operation.  If the fields are non-atomic, such loads are considered
+  data races and violate the data race free requirement of the C/C++
+  language standard and thus the program has no semantics.
+
+The C/C++ memory model formalizes synchronization in terms of a {\it
+  happens-before} relation.  The C/C++ happens-before relationship
+is a partial order over memory accesses.  If memory access {\it x}
+happens before memory access {\it y}, it means that the effects of
+{\it x} must be ordered before  the effects of {\it y}. 
+\countend
+
+\begin{figure}
+        \centering
+\vspace{-.3cm}
+       \includegraphics[scale=0.35]{figures/specworkflow}
+\vspace{-.4cm}
+               \caption{\label{fig:specworkflow} \TOOL system overview}
+\vspace{-.4cm}
+\end{figure}
+
+\mysubsection{Specification Language and Tool Support}
+
+Figure~\ref{fig:specworkflow} presents an overview of the \TOOL system. After
+implementing a concurrent data structure, developers annotate their code
+with a \TOOL specification. To test their implementation,
+developers compile the data structure with the \TOOL specification
+compiler to extract the specification and generate a program that is instrumented with specification checks.
+ Then, developers compile the instrumented program with a
+standard C/C++ compiler. Finally, developers run the binary under 
+the \TOOL checker. \TOOL
+then exhaustively explores the behaviors of the specific unit test and
+generates diagnostic reports for any executions that violate the specification.
+
+\mysubsection{Contributions}
+
+This paper makes the following contributions:
+
+\begin{itemize}
+\item {\bf Specification Language:} It introduces a specification
+  language that enables developers to write specifications of
+  concurrent data structures developed for a relaxed memory model in a
+  simple fashion that captures the key correctness properties.  Our
+  specification language is the first to our knowledge that supports concurrent data
+  structures that use C/C++ atomic operations.
+
+\item {\bf A Technique to Relate Concurrent Executions to Sequential Executions:}  It presents an approach to order the memory operations for the
+  C/C++ model, which lacks a definition of a trace and for which one
+  generally cannot even construct a total order of atomic operations
+  that is consistent with the program order.  The generated
+  sequential execution by necessity does not always maintain program order.
+  
+\item {\bf Synchronization Properties:} It presents constructs
+  for specifying the happens before relations that a data structure
+  should establish and tool support for checking these properties and
+  exposing synchronization related bugs.
+
+\item {\bf Tool for Checking C/C++ Data Structures Against Specifications:} \TOOL is the first tool to our knowledge that can check concurrent data structures that exhibit relaxed behaviors against specifications that are specified in terms intuitive sequential executions.
+
+\item {\bf Evaluation:} It shows that the \TOOL specification language can express key correctness properties for a
+set of real-world concurrent data structures, that our tool can detect
+  bugs, and that our tool can unit test real world data structures
+  with reasonable performance.
+\end{itemize}
+
diff --git a/correctness-model/writeup/.#memorymodel.tex.1.1 b/correctness-model/writeup/.#memorymodel.tex.1.1
new file mode 100644 (file)
index 0000000..f60d9da
--- /dev/null
@@ -0,0 +1,101 @@
+\section{C/C++ Memory Model}\label{sec:memorymodel}
+
+We next briefly summarize key aspects of the C/C++ memory model.  The memory model describes a series of atomic operations and the
+corresponding allowed behaviors of programs that utilize them.
+
+Any operation on an atomic object will have one of six \textit{memory orders},
+each of which falls into one or more of the following categories.
+
+\begin{description}
+
+       \item[relaxed:]
+               \code{memory\_order\_relaxed} --
+               weakest memory ordering
+
+       \item[release:]
+               \code{memory\_order\_release},
+               \code{memory\_order\_acq\_rel}, and
+               \code{memory\_order\_seq\_cst} --
+               a store-release may form release/consume or release/acquire synchronization
+
+       \item[consume:\footnotemark{}]
+               \code{memory\_order\_consume} --
+               a load-consume may form release/consume synchronization
+
+               \footnotetext{Consume is not broadly supported by compilers at
+      this point due to specifying data dependencies. We treat consumes as acquires.}
+    
+       \item[acquire:]
+               \code{memory\_order\_acquire},
+               \code{memory\_order\_acq\_rel}, and
+               \code{memory\_order\_seq\_cst} --
+               a load-acquire may form release/acquire synchronization
+
+       \item[seq-cst:]
+               \code{memory\_order\_seq\_cst} --
+               strongest memory ordering
+
+\end{description}
+
+\subsection{Relations}\label{sec:model-relations}
+
+The C/C++ memory model expresses program behavior in the form
+of binary relations or orderings. The following subsections will briefly
+summarize the relevant relations. Much of this discussion resembles the preferred model from the 
+formalization in \cite{c11popl}.
+
+\mypara{\bf Sequenced-Before:}
+The order of program operations within a single thread of execution establishes an intra-thread
+\textit{sequenced-before} (\reltext{sb}) relation.
+Note that while some operations in C/C++ provide no
+intra-thread ordering---the equality operator (\code{==}), for example---we
+ignore this detail and assume that \reltext{sb} totally orders all operations in
+a thread.
+
+\mypara{\bf Reads-From:}
+The \textit{reads-from} (\reltext{rf}) relation consists of store-load pairs $(X, Y)$
+such that $Y$ reads its value from the effect of $X$---or $X \relation{rf} Y$. In the
+C/C++ memory model, this relation is non-trivial, as a given load operation may
+read from one of many potential stores in the program execution.
+
+\mypara{\bf Synchronizes-With:}
+The \textit{synchronizes-with} (\reltext{sw}) relation captures
+synchronization that occurs when certain atomic operations interact across two
+threads. For instance, release/acquire synchronization occurs between a pair of
+atomic operations on the same object: a store-release $X$ and a load-acquire
+$Y$. If $Y$ reads from $X$, then $X$ synchronizes with $Y$---or $X
+\relation{sw} Y$. Synchronization also occurs between consecutive unlock and
+lock operations on the same mutex, between thread creation and the first event
+in the new thread, and between the last action of a thread and the completion of
+a thread-join operation targeting that thread.
+
+\mypara{\bf Happens-Before:}
+In \TOOL, we avoid consume operations, and so the \textit{happens-before}
+(\reltext{hb}) relation is simply the transitive closure of \reltext{sb} and
+\reltext{sw}.
+
+The \reltext{hb} relation restricts the stores that loads can read
+from.  For example, if we have two stores $X$ and $Y$ and
+a load $Z$ to the same memory location and $X \relation{hb} Y
+\relation{hb} Z$, then $Z$ cannot read from $X$.
+
+\mypara{\bf Sequential Consistency:}
+All seq-cst operations in a program execution form a
+total ordering (\reltext{sc}) so that, for instance, a seq-cst load may not read
+from a seq-cst store prior to the most recent store (to the same location) in
+the \reltext{sc} ordering, nor from any store that happens before that store.
+The \reltext{sc} order must be consistent with \reltext{hb}.
+
+\mypara{\bf Modification Order:}
+Each atomic object in a program execution has an associated \textit{modification order}
+(\reltext{mo})---a total order of all stores to that object---which
+informally represents a memory-coherent ordering in which those stores may be observed by
+the rest of the program.
+Note that
+in general the modification orders for all objects cannot be combined
+to form a consistent total ordering. We use $X \relation{mo} Y$ to represent the
+fact that $X$ is modification ordered before $Y$.
+
+
+
+
diff --git a/correctness-model/writeup/.#specification.tex.1.47 b/correctness-model/writeup/.#specification.tex.1.47
new file mode 100644 (file)
index 0000000..cb2aa21
--- /dev/null
@@ -0,0 +1,419 @@
+\mysection{Specification Language Design}\label{sec:specification}
+
+We begin by briefly overviewing \TOOL's basic approach.  The \TOOL
+specification language specifies the correctness properties for
+concurrent data structures by establishing a correspondence with an
+equivalent sequential data structure, which requires: (1) defining the
+equivalent sequential data structure; (2) establishing an equivalent
+sequential history; (3) relating the behavior of the concurrent
+execution to the sequential history; and (4) specifying the
+synchronization properties between method invocations. The \TOOL
+specification language has the following key components:
+
+\mypara{\bf 1. Equivalent Sequential Data Structure:} This component defines a 
+sequential data structure against which the concurrent data structure
+will be checked.
+
+\mypara{\bf 2. Defining the Equivalent Sequential History:}
+For real-world data structures, generally there exist two types of API methods,
+\textit{primitive} API methods and \textit{aggregate} API methods. Take
+concurrent hashtables as an example, it provides primitive API methods
+such as \code{put} and \code{get} that implement the core functionality of the
+data structure, and it also has aggregate API methods such
+as \code{putAll} that calls primitive API methods internally. From our
+experience working with our benchmark set, it is generally possible to
+generate a sequential history of primitive API method invocations for
+real-world data structures as they generally serialize on a single memory
+location --- while it is possible to observe partially completed aggregate
+API method invocations.  Therefore, our specifications will focus on the
+correctness of primitive API methods.
+
+Borrowing from VYRD~\cite{vyrd} the concept of commit points, we allow
+developers to specify \textit{ordering points} --- the specific atomic
+operations between method invocation and response events that are used for
+ordering method calls.  Ordering points are a generalization of the commit
+points as they also use memory operations that do not commit the data structure
+operation to order method calls. Developers then specify ordering points to
+generate the equivalent sequential history.
+
+\mypara{\bf 3. Specifying Correct Behaviors:} Developers use
+the \TOOL specification to provide a set of \textit{side effects}
+and \textit{assertions} to describe the desired behavior of each API
+method.  Side effects capture how a method updates the equivalent
+sequential data structure.  Assertions include both preconditions and
+postconditions which specify what conditions each method must satisfy
+before and after the method call, respectively. The specification of
+the side effects and assertions may make use of the states of the
+equivalent sequential data structure, meaning that these components
+can access the internal variables and methods of the equivalent sequential data
+structure. Additionally, they can reference the values available at
+the method invocation and response, i.e., the parameter values and the
+return value.
+
+\mypara{\bf 4. Synchronization:} The synchronization  specification
+describes the desired happens before relations between API method
+invocations.  \TOOL specifications allow developers to specify the
+properties at the abstraction of methods.  This makes specifications
+cleaner, more understandable, and less error-prone because the
+properties do not rely on low-level implementation
+details. Moreover, \TOOL specifications allow developers to attach
+conditions to methods when specifying synchronization properties so
+that a method call might synchronize with another only under a
+specific condition.  For example, consider a spin lock with
+a \code{try\_lock()} method, we need to specify that only a
+successful \code{try\_lock()} method invocation must synchronize with the
+previous \code{unlock()} method invocation.
+
+Figure~\ref{fig:speccfg} presents the grammar for the \TOOL specification
+language.  The grammar defines three types of specification annotations: 
+\textit{structure annotations}, \textit{method annotations}, and
+\textit{ordering point annotations}.
+In the grammar, \textit{code} means legal C/C++ source code; and
+\textit{label} means legal C/C++ variable name.
+Annotations are embedded in C/C++ comments.
+This format does not affect the semantics of the original
+program and allows for the same source to be used by both a standard C/C++
+compiler to generate production code and for the \TOOL specification compiler to
+extract the \TOOL specification from the comments.  We discuss these constructs in more detail throughout the remainder of this section.
+
+\begin{figure}[!tb]
+\vspace{-.2cm}
+{\scriptsize
+       \begin{eqnarray*}
+       \textit{\textbf{structureSpec}} & \rightarrow & \code{"@Structure\_Define"}\\ 
+ && \textit{structureDefine} \ \ \ (\textit{happensBefore})?\\
+       \textit{structureDefine} & \rightarrow & 
+(\code{"@DeclareStruct:"} \ 
+       \textit{code})\text{*}\\
+       && \code{"@DeclareVar:"} \ \textit{code}\\
+       && \code{"@InitVar:"} \ \textit{code}\\
+       && (\code{"@DefineFunc:"} \ \textit{code})\text{*}\\
+       \textit{happensBefore} & \rightarrow & \code{"@Happens\_Before:"} \
+       (\textit{invocation} \ \code{"->"} \
+       \textit{invocation})\textsuperscript{+}\\
+       \textit{invocation} & \rightarrow & \textit{label} \ (\ \  \code{"("} \
+       \textit{label} \code{")"} \ \ )?\\
+       \textit{\textbf{methodSpec}} & \rightarrow & \code{"@Method:"} \ \textit{label}\\
+       && \code{"@Ordering\_Point\_Set:"} \ \textit{label} \ (\code{"|"} \
+       \textit{label})\text{*}\\
+       && (\code{"@HB\_Condition:"} \ \textit{label} \ \code{"::"} \ \textit{code})\text{*}\\
+       && (\code{"@ID:"} \ \textit{code})?\\
+       && (\code{"@PreCondition:"} \ \textit{code})?\\
+       && (\code{"@SideEffect:"} \ \textit{code})?\\
+       && (\code{"@PostCondition:"} \ \textit{code})?\\
+       \textit{\textbf{potentialOP}} & \rightarrow & \code{"@Potential\_Ordering\_Point:"} \ \textit{code}\\
+       && \code{"@Label:"} \ \ \textit{label}\\
+       \textit{\textbf{opCheck}} & \rightarrow & \code{"@Ordering\_Point\_Check:"} \ \textit{code}\\
+       && \code{"@Potential\_Ordering\_Point\_Label:"} \ \textit{label}\\
+       && \code{"@Label:"} \ \ \textit{label}\\
+       \textit{\textbf{opLabelCheck}} & \rightarrow & \code{"@Ordering\_Point\_Label\_Check:"} \ \textit{code}\\
+       && \code{"@Label:"} \ \ \textit{label}\\
+       \textit{\textbf{opClear}} & \rightarrow & \code{"@Ordering\_Point\_Clear:"} \ \textit{code}\\
+       && \code{"@Label:"} \ \ \textit{label}\\
+       \textit{code} & \rightarrow & \code{<Legal C/C++ code>}
+       \end{eqnarray*}}
+\vspace{-.7cm}
+\caption{\label{fig:speccfg}Grammar for \TOOL specification language}
+\vspace{-.3cm}
+\end{figure}
+
+
+\mysubsection{Example}
+
+To make the \TOOL specification language more concrete,
+Figure~\ref{fig:rcuSpecExample} presents the annotated RCU example. We
+use {\it ordering points} to order the method invocations to construct
+the equivalent sequential history for the concurrent execution.  We
+first specify the ordering points for the \code{read}
+and \code{update} methods to help define the equivalent sequential
+history. For the
+\code{read} method, the load access of the \code{node} field in
+Line~\ref{line:rcuSpecReadLoad} is the only operation that can be an ordering
+point.  For the \code{update} method, there exists more than one atomic
+operation, however they only serve as an ordering point when it successfully uses the CAS operation
+to update the \code{node} field. Thus, we specify in
+Line~\ref{line:rcuSpecUpdateOPBegin} that the CAS operation should be the
+ordering point for the update operation when \code{succ} is \code{true}. We
+associate the methods with the two ordering points in 
+Line~\ref{line:rcuSpecReadInterfaceOPSet} and
+\ref{line:rcuSpecUpdateInterfaceOPSet}.
+
+Next, we specify the equivalent sequential data structure for this RCU implementation.
+Line~\ref{line:declVar} declares two integer fields \code{\_data} and
+\code{\_version} as the internal states of the equivalent sequential RCU, and
+Line~\ref{line:initVar} initializes both variables to \code{0}.
+
+We then specify the correct behaviors of the equivalent sequential
+history by defining the side effects and assertions for
+the \code{read} and \code{update} methods.  Side effects specify how
+to perform the corresponding operation on the equivalent sequential
+data structure.  For example,
+Line~\ref{line:rcuSpecUpdateInterfaceSideEffect} specifies the side
+effects of the \code{update} to the sequential states.
+Assertions specify properties that should be true of the concurrent data structure execution.
+For example, Line~\ref{line:rcuSpecReadInterfacePostCondition}
+specifies that the \code{read} method should satisfy the postcondition that the
+returned \code{data} and \code{version} fields should have consistent values
+as the internal state of the equivalent sequential data structure.
+
+Our implementation of the RCU data structure is designed to establish
+synchronization between the \code{update} method invocation and the later
+\code{read} or \code{update} method invocation.  This is important, for
+example, if a client thread were to update an array index and use the RCU data
+structure to communicate the updated index to a second client thread.  Without
+synchronization, the second client thread may not see the update to the array
+index. Besides, the synchronization between two \code{update} calls ensures that
+later \code{read} will see the most updated values.
+In order to specify the synchronization, we associate \code{read} and \code{update} methods with method call identifiers
+(Line~\ref{line:rcuSpecReadInterfaceID} and Line~\ref{line:rcuSpecUpdateInterfaceID}), which for this example is the value of the
+\code{this} pointer.
+Together these annotations ensure that every
+API method call on the same RCU object will have the same method call ID. 
+Line~\ref{line:rcuSpecHB} then specifies
+the synchronization property for the RCU --- any \code{update} method invocation
+should synchronize with all later \code{read} and \code{update} method invocations that have the
+same method call identifier as that \code{update} method. This guarantees that
+\code{update} calls should synchronize with the \code{read} and \code{update}
+calls of the same RCU object.
+
+
+\begin{figure}[h!]
+\vspace{-.2cm}
+\begin{lstlisting}[xleftmargin=6.0ex]
+class RCU {
+       /** @Structure_Define:
+               @DeclareVar:/*@ \label{line:declVar} @*/ int _data, _version;
+               @InitVar:/*@ \label{line:initVar} @*/ _data = 0; _version = 0;
+       @Happens_Before: Update->Read  Update->Update*//*@ \label{line:rcuSpecHB} @*/
+       atomic<Node*> node;
+       public:
+       RCU() {
+               Node *n = new Node;
+               n->data = 0;
+               n->version = 0;
+               atomic_init(&node, n);  
+       }
+       /** @Interface: Read/*@ \label{line:rcuSpecReadInterfaceLabel} @*/
+       @Ordering_Point_Set: Read_Point/*@ \label{line:rcuSpecReadInterfaceOPSet} @*/
+       @ID: this/*@ \label{line:rcuSpecReadInterfaceID} @*/
+       @PostCondition:/*@ \label{line:rcuSpecReadInterfacePostCondition} @*/
+               _data == *data && _version == *version *//*@ \label{line:rcuSpecReadInterfaceEnd} @*/
+       void read(int *data, int *version) {
+               Node *res = node.load(mo_acquire);/*@ \label{line:rcuSpecReadLoad} @*/
+               /** @Ordering_Point_Label_Check: true/*@ \label{line:rcuSpecReadOPBegin} @*/
+               @Label: Read_Point */
+               *data = res->data;
+               *version = res->version;
+       }
+       /** @Interface: Update 
+       @Ordering_Point_Set: Update_Point/*@ \label{line:rcuSpecUpdateInterfaceOPSet} @*/
+       @ID: this/*@ \label{line:rcuSpecUpdateInterfaceID} @*/
+       @SideEffect: _data = data; _version++; *//*@ \label{line:rcuSpecUpdateInterfaceSideEffect} @*/
+       void update(int data) {
+               bool succ = false;
+               Node *newNode = new Node;/*@ \label{line:rcuSpecUpdateAlloc} @*/
+               Node *prev = node.load(mo_acquire);/*@ \label{line:rcuSpecUpdateLoad} @*/
+               do {
+                       newNode->data = data;
+                       newNode->version = prev->version + 1;
+                       succ = node.compare_exchange_strong(prev,/*@\label{line:rcuSpecUpdateCAS} @*/
+                               newNode, mo_acq_rel, mo_acquire);
+                       /** @Ordering_Point_Label_Check: succ/*@ \label{line:rcuSpecUpdateOPBegin} @*/
+                       @Label: Update_Point */
+               } while (!succ);
+       }
+};
+
+\end{lstlisting}
+\vspace{-.2cm}
+\caption{\label{fig:rcuSpecExample}Annotated RCU specification example}
+\vspace{-.3cm}
+\end{figure}
+
+\subsection{Defining the Equivalent Sequential History}
+
+While defining the equivalent sequential history for concurrent executions is well studied in the context of the
+SC memory model, optimizations that developers typically use in the
+context of weaker memory models create the following new challenges when
+we generate the equivalent sequential history using ordering points.
+
+\begin{itemize}
+\item {\bf Absence of a Meaningful Trace or Total Order:}
+For the SC memory model, an execution can be represented by a simple
+interleaving of all the memory operations, where each load operation reads from
+the last store operation to the same location in the trace.  However, under a
+relaxed memory model like C/C++11, the interleaving does not uniquely define an
+execution because a given load operation can potentially read from many
+different store operations in the interleaving. Therefore, we have to rely on
+the intrinsic relations between ordering points such as \textit{reads from} and
+\textit{modification order} to order method calls.
+
+\item {\bf Lack of Program Order Preserving Sequential History:}
+Moreover, as discussed in Section~\ref{sec:exampleMotivation}, in
+general it is not possible to arrange an execution in any totally
+ordered sequential history that preserves program order.
+
+A key insight is that many concurrent data structures' API methods
+have a commit point, which is a single memory operation that makes the
+update visible to other threads and that also serves as an ordering
+point.  When two data structure operations have a dependence, it is
+often the case that their respective commit points are both
+conflicting accesses to the same memory location.  In this case, the
+modification order provided by C/C++ is sufficient to order these
+operations since modification order is guaranteed to be consistent
+with the happens before relation (and therefore also the sequenced
+before relation).
+
+For cases where the method calls are independent, such as
+a \code{put(X, 1)} followed by a
+\code{get(Y)} in a hashtable where \code{X} and \code{Y} are different keys,
+the lack of an ordering is not a problem since those methods commute.
+\end{itemize}
+
+\mypara{\bf Ordering Point Annotations:} In many cases, it is not
+possible to determine whether a given atomic operation is an ordering 
+point until later in the execution. For example, 
+some internal methods may be called by multiple API methods. In this
+case, the same atomic operation can be identified as a potential
+ordering point for multiple API methods, and each API method later has
+a checking annotation to verify whether it was a real ordering
+point.  Therefore, the \TOOL specification separates the definition of ordering
+points as follows:
+\begin{enumerate}
+\vspace{-.1cm}
+\item {\code{Potential\_Ordering\_Point} annotation:} The labeling of ordering
+points that identifies the location of a potential ordering point.
+\vspace{-.2cm}
+\item {\code{Ordering\_Point\_Check} annotation:} The checking of ordering
+points that checks at a later point whether a potential ordering point was
+really an ordering point.
+\end{enumerate}
+\vspace{-.1cm}
+
+These two constructs together identify ordering points.  For
+example, assume that $A$ is an atomic operation that is marked as a
+potential ordering point with the label \code{LabelA} under the
+condition \code{ConditionA}.  The developer would write a
+\code{Potential\_Ordering\_Point} annotation with the label
+\code{LabelA} and then use the label \code{LabelA} in an
+\code{Ordering\_Point\_Check} annotation at a later point.
+
+The \code{Ordering\_Point\_Label\_Check} annotation combines
+the \code{Potential\_Ordering\_Point} and the
+\code{Ordering\_Point\_Check} annotations, and makes
+specifications simpler for the use case that the ordering point is known immediately.
+For example, in Line~\ref{line:rcuSpecReadOPBegin} of
+Figure~\ref{fig:rcuSpecExample}, we use the \code{Ordering\_Point\_Label\_Check} annotation to
+identify the ordering point for \code{read} because we know the load operation
+in Line~\ref{line:rcuSpecReadLoad} is an ordering point at the time it is
+executed.
+
+Some data structure operations may require multiple ordering points.
+For example, consider a transaction implementation that first attempts
+to lock all of the involved objects (dropping the locks and retrying
+if it fails to acquire a lock), performs the updates, and then releases
+the locks.  To order such transactions in a relaxed memory model, we must consider all of the
+locks it acquires and not just the last lock.  Thus, we allow a
+method invocation to have more than one ordering point, and the
+additional ordering points serve to order the operation with respect to
+multiple different memory locations.  For the transaction example, it
+may be necessary to retry the acquisition of locks.  To support this
+scenario, the \code{Ordering\_Point\_Clear} annotation removes all
+previous ordering points when it satisfies a specific condition.
+
+Moreover, when an API method calls another API method, they can share ordering points.  In
+that case, \TOOL requires that at that ordering point, the concurrent data
+structure should satisfy the precondition and postcondition of both the inner
+and outer API methods.
+
+\subsection{Checking the IO Behavior of Methods}
+
+With the specified ordering points, \TOOL is able to generate the equivalent
+sequential history. Developers then need to define the equivalent sequential
+data structure. For example, in Line~\ref{line:declVar} and
+~\ref{line:initVar} of the annotated RCU example, we use the
+\code{Structure\_define} annotation to define the equivalent sequential RCU
+by specifying the internal states as two integers, \code{\_verion} and \code{\_data}. In the
+\code{Structure\_define} annotation, developers can also specify definitions for customized
+structs and methods for convenience. We design these annotations in such a way
+that developers can  
+write specifications in C/C++ code such that they do not have to learn a new
+specification language.
+
+After defining the internal states and methods of the
+equivalent data structure, developers use the \code{SideEffect} annotation to
+define the corresponding sequential API methods, which should contain the action
+to be performed on the equivalent sequential data structure. For example, in
+Line~\ref{line:rcuSpecUpdateInterfaceSideEffect} of the annotated RCU example,
+we use \code{SideEffect} to specify that when we execute the \code{update}
+method on the equivalent sequential RCU, we should update the
+internal states of \code{\_version} and \code{\_data} accordingly. When
+the \code{SideEffect} annotation is omitted for a specific API method, it means
+that no side effects will happen on the sequential data structure when that
+method is called. Take the annotated RCU as an example, the \code{read} has no
+side effects on the equivalent sequential RCU.
+
+With the well-defined equivalent sequential data structure, developers then relate
+the generated equivalent sequential history to the equivalent sequential data
+structure. In \TOOL, we allow developers to accomplish this by using the
+\code{PreCondition} and \code{PostCondition} annotations to specify the
+conditions to be checked before and after the API method appears to happen.
+For example, Line~\ref{line:rcuSpecReadInterfaceEnd} in the
+annotated RCU example means that when \code{read} appears to happen, it should
+return the same value as the current interal variables of the equivalent
+sequential RCU.
+Note that these two annotations contain legitimate C/C++
+expressions that only access the method call parameters, return value and the
+internal states of the equivalent sequential data structure.
+
+\subsection{Checking Synchronization}
+
+Under a relaxed memory model, compilers and processors can reorder
+memory operations and thus the execution can exhibit counter-intuitive
+behaviors. The C/C++11 memory model provides the developer with memory ordering that establish synchronization, e.g., \code{acquire}, \code{release}, \code{seq\_cst}.  Synchronization 
+serves to control which reorderings are allowed --- however,
+restricting reorderings comes at a runtime cost so developers must
+balance complexity against runtime overhead.  Checking that data
+structures establish proper synchronization is important to ensure
+that the data structures can be effectively composed with client code.
+
+We generalize the notion of happens before to methods as follows.
+Method call $c_1$ happens-before method call $c_2$ if the invocation
+event of $c_1$ happens before the response event of $c_2$.  Note that
+by this definition two method calls can both happen before each other
+--- an example of this is the \code{barrier} synchronization
+construct.  For example, for a correctly synchronized queue, we want
+an enqueue to happen before the corresponding dequeue, which avoids
+the synchronization problems discussed earlier in
+Section~\ref{sec:introNewChallenges}.
+
+In order to flexibly express the synchronization between methods, we associate
+API methods with method call identifiers (or IDs) and happens-before conditional guard
+expressions. The method
+call ID is a C/C++ expression that computes a unique ID for the call, and if it
+is omitted, a default value is used. For example, in our RCU example in
+Figure~\ref{fig:rcuSpecExample}, method \code{update} and \code{read} both
+have the \code{this} pointer of the corresponding RCU object.
+The \code{HB\_Condition} component
+associates one happens-before conditional guard expression with a unique label.
+For one method, multiple conditional guard expressions are allowed to be
+defined, and the conditional guard expression can only access the method
+instance's argument values and return value. 
+
+After specifying the
+method call IDs and the \code{HB\_Condition} labels, developers
+can specify the synchronization as ``\code{method1(HB\_condition1)} \code{->}
+\code{method2(HB\_condition2)}''. When the \code{HB\_condition} is omitted, it
+defaults to \code{true}. The semantics of this expression is that all
+instances of calls to \code{method1} that satisfy the conditional guard
+expression \code{HB\_condition1} should happen-before all later instances (as determined by ordering points) of
+calls to \code{method2} that satisfy the conditional guard expression
+\code{HB\_condition2} such that both instances shared the same ID.
+The ID and happens-before conditional guard expression are important because they
+allow developers to impose synchronization only between specific method
+invocations under specific conditions. For example, in
+Figure~\ref{fig:rcuSpecExample}, Line~\ref{line:rcuSpecHB} specifies two
+synchronization rules, which together mean that the
+\code{update} should only establish synchronization with later \code{read} and
+\code{update} from
+the same RCU object under all circumstances.
diff --git a/correctness-model/writeup/CVS/Entries b/correctness-model/writeup/CVS/Entries
new file mode 100644 (file)
index 0000000..e738c4e
--- /dev/null
@@ -0,0 +1,19 @@
+/confstrs-abbrv.bib/1.1/Wed Jan 14 22:53:32 2015//
+/confstrs-long.bib/1.1/Wed Jan 14 22:53:32 2015//
+/sig-alternate.cls/1.1/Wed Jan 14 22:53:32 2015//
+D/figures////
+/makefile/1.2/Fri Jan 23 17:16:19 2015//
+/spell.lst/1.1/Fri Jan 23 05:47:30 2015//
+/abstract.tex/1.2/Fri Jan 23 22:58:26 2015//
+/conclusion.tex/1.2/Fri Jan 23 22:58:26 2015//
+/related.tex/1.2/Fri Jan 23 22:58:26 2015//
+/speccfg.tex/1.1/Fri Jan 23 22:58:26 2015//
+/technical.tex/1.1/Fri Jan 23 22:58:26 2015//
+/paper.tex/1.6/Fri Jan 23 23:30:25 2015//
+/paper.bib/1.3/Sat Jan 24 00:47:32 2015//
+/memorymodel.tex/1.8/Sat Jan 24 01:51:58 2015//
+/introduction.tex/1.36/Sat Jan 24 03:09:04 2015//
+/example.tex/1.19/Sat Jan 24 03:36:11 2015//
+/specification.tex/1.59/Sat Jan 24 04:47:54 2015//
+/implementation.tex/1.16/Sat Jan 24 05:04:07 2015//
+/evaluation.tex/1.21/Sat Jan 24 05:35:18 2015//
diff --git a/correctness-model/writeup/CVS/Repository b/correctness-model/writeup/CVS/Repository
new file mode 100644 (file)
index 0000000..e5a4afa
--- /dev/null
@@ -0,0 +1 @@
+Papers/15/issta.cdsspec
diff --git a/correctness-model/writeup/CVS/Root b/correctness-model/writeup/CVS/Root
new file mode 100644 (file)
index 0000000..cd8b2f1
--- /dev/null
@@ -0,0 +1 @@
+:ext:peizhaoo@plrg.eecs.uci.edu:/home/cvs/Papers
diff --git a/correctness-model/writeup/abstract.tex b/correctness-model/writeup/abstract.tex
new file mode 100644 (file)
index 0000000..7bf3748
--- /dev/null
@@ -0,0 +1,19 @@
+Concurrent data structures often provide better performance on
+multi-core platforms, but are significantly more difficult to design and
+verify than their sequential counterparts.  The C/C++11 standard
+introduced a weak language memory model supporting low-level atomic
+operations such as compare and swap (CAS).  While these
+atomic operations can significantly improve the performance
+of concurrent data structures, programming at this level
+introduces
+non-intuitive behaviors that significantly increase the difficulty of
+developing code.
+
+In this paper, we present \TOOL, a specification language checker that
+allows developers to write simple specifications for low-level
+concurrent data structures that make use of C/C++11 atomics and check
+the correctness of concurrent data structures against these
+specifications.  \TOOL is designed to be used in conjunction with
+model checking tools and we have implemented it as a plugin
+to \cdschecker.  We have evaluated \TOOL by annotating and checking
+several concurrent data structures.
diff --git a/correctness-model/writeup/conclusion.tex b/correctness-model/writeup/conclusion.tex
new file mode 100644 (file)
index 0000000..ae07691
--- /dev/null
@@ -0,0 +1,11 @@
+\mysection{Conclusion\label{sec:conclusion}}
+
+The \TOOL specification language and checking system makes it easier
+to unit test concurrent data structures written for the C/C++11 memory
+model.  It extends and modifies classic approaches to defining the
+desired behaviors of concurrent data structures with respect to
+sequential versions of the same data structure to
+apply to the C/C++ memory model.  Our evaluation shows
+that the approach can be used to specify and test correctness
+properties for a range of data structures including a
+lock-free hashtable, work-stealing deque, queues and locks.
diff --git a/correctness-model/writeup/confstrs-abbrv.bib b/correctness-model/writeup/confstrs-abbrv.bib
new file mode 100644 (file)
index 0000000..ef42052
--- /dev/null
@@ -0,0 +1,173 @@
+@string{mspc12="MSPC"}
+@string{ppdp11="PPDP"}
+@string{spin04="SPIN"}
+@string{spin07="SPIN"}
+@string{spin08="SPIN"}
+@string{spin09="SPIN"}
+@string{ijpp="IJPP"}
+@string{jlap="JLAP"}
+@string{fcad10="FCAD"}
+@strign{sc="SC"}
+@string{iwops99="POS"}
+@string{podc96="PODC"}
+@string{popl73="POPL"}
+@string{popl93="POPL"}
+@string{popl96="POPL"}
+@string{popl97="POPL"}
+@string{popl99="POPL"}
+@string{popl05="POPL"}
+@string{popl07="POPL"}
+@string{popl08="POPL"}
+@string{popl09="POPL"}
+@string{popl11="POPL"}
+@string{popl13="POPL"}
+
+@string{dac07="DAC"}
+@string{sosp05="SOSP"}
+@string{sosp03="SOSP"}
+@string{oopsla02="OOPSLA"}
+@string{oopsla03="OOPSLA"}
+@string{oopsla04="OOPSLA"}
+@string{oopsla05="OOPSLA"}
+@string{oopsla06="OOPSLA"}
+@string{oopsla07="OOPSLA"}
+@string{oopsla08="OOPSLA"}
+@string{oopsla09="OOPSLA"}
+@string{oopsla10="OOPSLA"}
+@string{oopsla13="OOPSLA"}
+
+@string{hotpar09="HotPar"}
+@string{hotpar10="HotPar"}
+
+@string{atc="ATC"}
+
+@string{ismm08="ISMM"}
+@string{ismm09="ISMM"}
+@string{ismm10="ISMM"}
+
+@string{esop09="ESOP"}
+
+@string{scool05="SCOOL"}
+
+@string{paste08="PASTE"}
+
+@string{ecoop10="ECOOP"}
+
+@string{osdi04="OSDI"}
+@string{osdi08="OSDI"}
+
+@string{toplas02="TOPLAS"}
+@string{toplas09="TOPLAS"}
+
+@string{pact01="PACT"}
+@string{pact08="PACT"}
+
+@string{cc08="CC"}
+@string{cc10="CC"}
+@string{cc11="CC"}
+
+@string{asplos91="ASPLOS"}
+@string{asplos02="ASPLOS"}
+@string{asplos09="ASPLOS"}
+
+@string{sc01="SC"}
+@string{sc06="SC"}
+
+@string{spaa98="SPAA"}
+@string{toplas="TOPLAS"}
+@string{tocs="TOCS"}
+@string{tpds="TPDS"}
+@string{vee05="VEE"}
+@string{vee08="VEE"}
+@string{jvm01="JVM"}
+
+@string{ics95="ICS"}
+@string{ics99="ICS"}
+
+@string{icse05="ICSE"}
+@string{icse10="ICSE"}
+@string{icse00="ICSE"}
+
+@string{sc97="SC"}
+@string{sc01="SC"}
+@string{lcpc08="LCPC"}
+@string{lcpc01="LCPC"}
+@string{pldi="PLDI"}
+@string{pldi93="PLDI"}
+@string{pldi94="PLDI"}
+@string{pldi95="PLDI"}
+@string{pldi96="PLDI"}
+@string{pldi97="PLDI"}
+@string{pldi98="PLDI"}
+@string{pldi99="PLDI"}
+@string{pldi00="PLDI"}
+@string{pldi01="PLDI"}
+@string{pldi02="PLDI"}
+@string{pldi03="PLDI"}
+@string{pldi04="PLDI"}
+@string{pldi05="PLDI"}
+@string{pldi06="PLDI"}
+@string{pldi07="PLDI"}
+@string{pldi08="PLDI"}
+@string{pldi09="PLDI"}
+@string{pldi10="PLDI"}
+@string{pldi11="PLDI"}
+@string{pldi12="PLDI"}
+@string{pldi13="PLDI"}
+
+@string{issta11="ISSTA"}
+@string{isca90="ISCA"}
+@string{isca09="ISCA"}
+@string{isca10="ISCA"}
+@string{ppopp97="PPoPP"}
+@string{ppopp01="PPoPP"}
+@string{ppopp07="PPoPP"}
+@string{ppopp09="PPoPP"}
+@string{ppopp10="PPoPP"}
+@string{ppopp11="PPoPP"}
+@string{ppopp12="PPoPP"}
+@string{ppopp13="PPoPP"}
+
+@string{cgo10="CGO"}
+@string{cgo11="CGO"}
+
+@string{ispass09="ISPASS"}
+
+@string{iiswc08="IISWC"}
+@string{iiswc09="IISWC"}
+
+@string{iccl88="ICCL"}
+
+@string{micro05="MICRO"}
+@string{micro10="MICRO"}
+
+@string{hpdc07="HPDC"}
+
+@string{cav08="CAV"}
+@string{cav07="CAV"}
+@string{cav06="CAV"}
+@string{cav04="CAV"}
+
+@string{procomet90="PROCOMET"}
+@string{hpca07="HPCA"}
+@string{dexa04="DEXA"}
+
+@string{lics="LICS"}
+@string{lncs="LNCS"}
+@string{lcpc="LCPC"}
+@string{vmcai="VMCAI"}
+@string{vmcai09="VMCAI"}
+@string{tacas11="TACAS"}
+
+@string{ieeecmpscieng="IEEE Comput. Sci. Eng."}
+@string{higherordersymbcomp="HOSC"}
+@string{ibmjrd="IBM J. of Res. Dev."}
+@string{ieeetc="TC"}
+@string{cacm="CACM"}
+@string{jsac="J-SAC"}
+
+@string{conpar90vappIV="CONPAR 90 - VAPP IV"}
+
+@string{asplos91="ASPLOS"}
+
+@string{ipdps09="IPDPS"}
diff --git a/correctness-model/writeup/confstrs-long.bib b/correctness-model/writeup/confstrs-long.bib
new file mode 100644 (file)
index 0000000..55ff861
--- /dev/null
@@ -0,0 +1,180 @@
+@string{mspc12="Proceedings of the 2012 ACM SIGPLAN Workshop on Memory Systems Performance and Correctness"}
+@string{ppdp11="Proceedings of the 13th International ACM SIGPLAN Symposium on Principles and Practices of Declarative Programming"}
+@string{padd88="Proceedings of the 1988 ACM SIGPLAN and SIGOPS Workshop on Parallel and Distributed Debugging"}
+@string{spin04="Proceedings of the 11th International {SPIN} Workshop on Model Checking Software"}
+@string{spin07="Proceedings of the 14th International {SPIN} Workshop on Model Checking Software"}
+@string{spin08="Proceedings of the 15th International {SPIN} Workshop on Model Checking Software"}
+@string{spin09="Proceedings of the 16th International {SPIN} Workshop on Model Checking Software"}
+@string{fcad10="Proceedings of the Conference on Formal Methods in Computer-Aided Design"}
+@string{jlap="Journal of Logic and Algebraic Programming"}
+@string{iwops99="Proceedings of the 8th International Workshop on Persistent Object Systems"}
+
+@string{ijpp="International Journal on Parallel Programming"}
+
+@string{sc06="Supercomputing"}
+@string{podc96="Proceedings of the Fifteenth Annual ACM Symposium on Principles of Distributed Computing"}
+@string{popl73="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl93="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl96="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl97="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl99="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl05="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl07="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl08="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl11="Proceedings of the Symposium on Principles of Programming Languages"}
+@string{popl13="Proceedings of the Symposium on Principles of Programming Languages"}
+
+@string{dac07="Proceedings of the 44th Annual Design Automation Conference"}
+
+@string{issta11="Proceedings of the 2011 International Symposium on Software Testing and Analysis"}
+
+@string{sosp03="Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles"}
+@string{sosp05="Proceedings of the Twentieth ACM Symposium on Operating Systems Principles"}
+@string{oopsla02="Proceeding of the 17th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla03="Proceeding of the 18th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla04="Proceeding of the 19th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla05="Proceeding of the 20th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla06="Proceeding of the 21st ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla07="Proceeding of the 22nd ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla08="Proceeding of the 23rd ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla09="Proceeding of the 24th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla10="Proceeding of the 25th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+@string{oopsla13="Proceeding of the 28th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications"}
+
+@string{scool05="Synchronization and Concurrency in Object-Oriented Languages"}
+
+@string{hotpar09="First USENIX Workshop on Hot Topics in Parallelism"}
+@string{hotpar10="Second USENIX Workshop on Hot Topics in Parallelism"}
+
+@string{atc="Proceedings of the USENIX Annual Technical Conference"}
+
+@string{ismm08="Proceedings of the 2008 International Symposium on Memory Management"}
+@string{ismm09="Proceedings of the 2009 International Symposium on Memory Management"}
+@string{ismm10="Proceedings of the 2010 International Symposium on Memory Management"}
+@string{esop09="Proceedings of the 2009 European Symposium on Programming"}
+@string{paste08="Proceedings of Program Analysis for Software Tools and Engineering"}
+
+@string{ecoop10="Proceedings of the 24th European Conference on Object-Oriented Programming"}
+
+@string{osdi04="Proceedings of the 6th Symposium on Operating Systems Design and Implementation"}
+@string{osdi08="Proceedings of the 8th Symposium on Operating Systems Design and Implementation"}
+
+@string{toplas02="ACM Transactions on Programming Languages and Systems"}
+@string{toplas09="ACM Transactions on Programming Languages and Systems"}
+
+@string{sc01="Proceedings of the ACM/IEEE Conference on Supercomputing"}
+@string{sc06="Proceedings of the ACM/IEEE Conference on Supercomputing"}
+
+@string{ics95="Proceedings of the 9th International Conference on Supercomputing"}
+
+@string{icse00="Proceedings of the 22nd International Conference on Software Engineering"}
+@string{icse05="Proceedings of the 27th International Conference on Software Engineering"}
+@string{icse10="Proceedings of the 32nd International Conference on Software Engineering"}
+
+@string{pact01="Proceedings of the 10th International Conference on Parallel Architectures and Compilation Techniques"}
+@string{pact08="Proceedings of the 17th International Conference on Parallel Architectures and Compilation Techniques"}
+
+@string{cc08="Proceedings of the 17th International Conference on Compiler Construction"}
+@string{cc10="Proceedings of the 19th International Conference on Compiler Construction"}
+@string{cc11="Proceedings of the 20th International Conference on Compiler Construction"}
+
+@string{asplos91="Proceedings of the Fourth International Conference on Architectural Support for Programming Languages and Operating Systems"}
+@string{asplos02="10th International Conference on Architectural Support for Programming Languages and Operating Systems"}
+@string{asplos09="14th International Conference on Architectural Support for Programming Languages and Operating Systems"}
+
+@string{vee05="Proceedings of the First ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments"}
+@string{vee08="Proceedings of the Fourth ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments"}
+
+@string{lcpc08="Proceedings of the 21st Annual Workshop on Languages and Compilers for Parallel Computing"}
+@string{lcpc10="Proceedings of the Fourteenth Annual Workshop on Languages and Compilers for Parallel Computing"}
+
+@string{pldi="Proceedings of Programming Language Design and Implementation"}
+@string{pldi93="Proceedings of the 1993 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi94="Proceedings of the 1994 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi95="Proceedings of the 1995 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi96="Proceedings of the 1996 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi97="Proceedings of the 1997 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi98="Proceedings of the 1998 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi99="Proceedings of the 1999 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi00="Proceedings of the 2000 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi01="Proceedings of the 2001 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi02="Proceedings of the 2002 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi03="Proceedings of the 2003 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi04="Proceedings of the 2004 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi05="Proceedings of the 2005 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi06="Proceedings of the 2006 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi07="Proceedings of the 2007 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi08="Proceedings of the 2008 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi09="Proceedings of the 2009 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi10="Proceedings of the 2010 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi11="Proceedings of the 2011 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi12="Proceedings of the 2012 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+@string{pldi13="Proceedings of the 2013 ACM SIGPLAN Conference on Programming Language Design and Implementation"}
+
+@string{isca90="Proceedings of the 17th Annual International Symposium on Computer Architecture"}
+@string{isca09="Proceedings of the 36th Annual International Symposium on Computer Architecture"}
+@string{isca10="Proceedings of the 37th Annual International Symposium on Computer Architecture"}
+
+@string{ppopp97="Proceedings of the 6th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming"}
+@string{ppopp07="Proceedings of the 12th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming"}
+@string{ppopp01="Proceedings of the 8th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming"}
+@string{ppopp09="Proceedings of the 14th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming"}
+@string{ppopp10="Proceedings of the 15th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming"}
+@string{ppopp11="Proceedings of the 16th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming"}
+@string{ppopp12="Proceedings of the 17th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming"}
+@string{ppopp13="Proceedings of the 18th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming"}
+
+@string{ispass09="IEEE International Symposium on Performance Analysis of Systems and Software"}
+
+@string{iiswc08="Proceedings of the IEEE International Symposium on Workload Characterization"}
+@string{iiswc09="Proceedings of the IEEE International Symposium on Workload Characterization"}
+
+@string{iccl88="Proceedings of the 1988 International Conference on Computer Languages"}
+
+@string{micro05="38th Annual IEEE/ACM International Symposium on Microarchitecture"}
+@string{micro10="43rd Annual IEEE/ACM International Symposium on Microarchitecture"}
+
+@string{hpdc07="Proceedings of the ACM International Symposium on High Performance Distributed Computing"}
+
+@string{cav07="Proceedings of the 19th International Conference on Computer Aided Verification"}
+@string{cav06="Proceedings of the 18th International Conference on Computer Aided Verification"}
+@string{cav08="Proceedings of the 20th International Conference on Computer Aided Verification"}
+@string{cav04="Proceedings of the 16th International Conference on Computer Aided Verification"}
+
+@string{tacas11="Proceedings of the 17th International Conference on Tools and Algorithms for the Construction and Analysis of Systems"}
+
+@string{procomet90="Proceedings of the International Conference on Programming Concepts and Methods"}
+
+@string{dexa04="Proceedings of the 15th International Conference on Database and Expert Systems Applications"}
+
+@string{lics="Symposium on Logic in Computer Science"}
+@string{lncs="Lecture Notes in Computer Science"}
+@string{lcpc="Proceedings of Languages and Compilers for Parallel Computing"}
+@string{vmcai="Proceedings of Verification, Model Checking, and Abstract Interpretation"}
+@string{vmcai09="Proceedings of the 2009 Conference on Verification, Model Checking, and Abstract Interpretation"}
+
+
+@string{ieeecmpscieng="IEEE Computing in Science and Engineering"}
+@string{higherordersymbcomp="Higher-Order and Symbolic Computation"}
+@string{ibmjrd="IBM Journal of Research and Development"}
+@string{ieeetc="IEEE Transactions on Computers"}
+@string{cacm="Communications of the ACM"}
+@string{jsac="IEEE Journal on Selected Areas in Communications"}
+@string{hpca07="Proceedings of the International Symposium on High Performance Computer Architecture"}
+@string{conpar90vappIV="Proceedings of the Joint International Conference on Vector and Parallel Processing"}
+@string{tocs="ACM Transactions on Computing Systems"}
+@string{toplas="ACM Transactions on Programming Languages and Systems"},
+@string{spaa98="Proceedings of the Tenth Annual ACM Symposium on Parallel Algorithms and Architectures"}
+@string{tpds="IEEE Transactions on Parallel and Distributed Systems"}
+
+@string{jvm01="Proceedings of the 2001 Symposium on JavaTM Virtual Machine Research and Technology"}
+@string{ics99="Proceedings of the International Conference on Supercomputing"}
+@string{sc97="Proceedings of the 1997 ACM/IEEE Conference on Supercomputing"}
+@string{sc01="Proceedings of the SC2001"}
+
+@string{cgo10="Proceedings of the 8th Annual IEEE/ACM International Symposium on Code Generation and Optimization"}
+@string{cgo11="Proceedings of the 9th Annual IEEE/ACM International Symposium on Code Generation and Optimization"}
+
+@string{asplos91="Proceedings of the Fourth International Conference on Architectural Support for Programming Languages and Operating Systems"}
+
+@string{ipdps09="Proceedings of the 2009 IEEE International Symposium on Parallel \& Distributed Processing"}
diff --git a/correctness-model/writeup/evaluation.tex b/correctness-model/writeup/evaluation.tex
new file mode 100644 (file)
index 0000000..1bf7c00
--- /dev/null
@@ -0,0 +1,304 @@
+\mysection{Evaluation}\label{sec:evaluation}
+
+We have implemented \TOOL.  Our evaluation focuses on the following
+questions: (1) How expressive is \TOOL for specifying
+the correctness properties of real-world concurrent data structures? (2) How easy is it
+to use \TOOL? (3) What
+is the performance of \TOOL? (4) How effective was \TOOL
+in finding bugs?
+
+In order to evaluate \TOOL, we have gathered a contention
+free lock, two types of concurrent queues, and a work stealing
+deque~\cite{ppoppworkstealing}.  As C/C++11 is relatively new
+there are no C/C++11 implementations for many concurrent data
+structures, thus we ported several data structures.  The Linux
+kernel's reader-writer spinlock and the Michael Scott queue were originally ported
+for the \cdschecker benchmark suite.  We also ported an RCU
+implementation and Cliff Click's hashtable from its Java
+implementation~\cite{clickhashtable}.  We report execution times on an 
+Intel Core i7 3770.
+
+\mysubsection{Expressiveness}\label{sec:expressiveness}
+
+In this section, we evaluate the expressiveness of \TOOL by reporting
+our experiences writing specifications for a range of concurrent data
+structures.
+
+\mypara{\bf Lockfree hashtable:} We ported Cliff Click's hashtable,
+which supports simultaneous lookups and updates by multiple threads as
+well as concurrent table resizing.  The implementation uses an array
+of atomic variables to store the key/value slots, and uses
+acquire/release synchronization to establish the synchronization
+between hashtable accesses.
+
+Hashtable updates consist of two CAS operations --- one to claim
+the key slot and one to update the value.  When a \code{put} method
+invocation successfully updates both the key and value, the
+update is visible to other threads.  Thus, both CAS operations are
+ordering points for the \code{put} method, and we annotate both of
+them as potential ordering points. The \code{get} method is ordered after
+an invocation of the \code{put} only if it sees both the key and
+value updates.  Thus we annotate an ordering point for the
+key read only if the key is null.  We also
+annotate an ordering point for the value read if
+it reads the value slot. The test driver has two threads both of
+which update and read the value for the same key.
+
+\mypara{\bf RCU:} As discussed in the example, this is a
+synchronization mechanism used in the Linux kernel that allows concurrent reads
+and updates. We ran this benchmark with four threads, two update the data
+structure and two read the data structure.
+
+\mypara{\bf Chase-Lev Deque:} This is a bug-fixed version of a published C11 adaptation
+of the Chase-Lev deque~\cite{ppoppworkstealing}.
+It maintains a top and bottom index to a shared array of
+references. In terms of synchronization,
+when pushing an item into the sequential deque,
+we attach a unique ID tag to that element. When stealing or taking an item, we
+use that tag as the ID of the method call. Thus, we have (push, steal) or
+(push, take) pairs that have the same method call ID.
+In our test driver, one thread 
+pushes 3 items and takes 2 items while the other one steals 1
+item.
+
+\mypara{\bf Linux Reader-Writer Lock:} A reader-writer lock allows either
+multiple concurrent readers or one exclusive writer. We can abstract
+it with a boolean \code{writer\_lock} representing
+whether the writer lock is held and an integer \code{reader\_cnt}
+representing the number of threads that are reading.
+We test this benchmark with a single lock that
+protects shared variables. We have two threads that read and write
+the shared variables under the protection of a read lock and a write
+lock.
+
+\mypara{\bf MCS Lock:} This benchmark is an implementation of
+the Mellor-Crummey and Scott lock~\cite{mcs-lock,
+  mcs-lock-url}.  This lock queues waiting threads in a FIFO.
+Our test driver utilizes two
+threads that read and write shared variables with the protection of
+the lock.
+
+\mypara{\bf M\&S Queue:} This benchmark is an adaptation of the
+Michael and Scott lock free queue~\cite{lockfreequeue} to the C/C++
+memory model.  We ran with two threads, one of which enqueues and the
+other of which dequeues an item.
+
+\mypara{\bf SPSC Queue:} This is a lock-free single-producer,
+single-consumer queue. 
+We used a test driver that has two
+threads --- one enqueues a value and the other  dequeues
+it.
+
+\mypara{\bf MPMC Queue:} This is a multiple-producer, multiple-consumer
+queue. Producers call \code{write\_prepare} to obtain a free
+slot, update the slot, and call \code{write\_publish} to
+publish it. Consumers call \code{read\_fetch} to obtain
+a valid slot, read the slot, and call \code{read\_consume}
+to free it. The specification focuses on the synchronization
+properties which require \code{write\_publish} to synchronize with
+\code{read\_fetch} to ensure the data integrity and
+\code{read\_consume} to synchronize with \code{write\_prepare} to
+ensure that slots are not prematurely recycled.  The test driver
+contains two threads, each of which enqueue and dequeue
+an item.
+
+\subsection{Ease of Use} In addition to expressiveness, it is also important for
+specification languages to be easy to use. In our experience using \TOOL
+to specify the real-world data
+structures in our benchmark set, we found that \TOOL was easy to use. \TOOL specifications have only three 
+parts --- equivalent sequential data structures, ordering points, and
+synchronization properties, and we explain the reasons as follows. (1) Specifying
+sequential data structures is easy and straightforward, and developers can often
+just use an off-the-shelf implementation from a library.
+(2) When developers specify ordering points, they
+only need to know what operations order methods without needing to specify
+the subtle reasoning about the corner cases involving
+interleavings and reorderings introduced by relaxed memory models. Take the
+Michael \& Scott queue as an example, we can easily order enqueuers with the
+point when \code{enqueue} loads the \code{tail} pointer right before inserting the new
+node.
+(3) For synchronization, the fact that we allow specifying
+synchronization at the abstraction of methods makes it easy. For example, we only used 
+36 lines to specify synchronization in a total 1,033 lines of
+code (omitting blanks and comments).
+
+\begin{figure}[!htb]
+\vspace{-.2cm}
+{\footnotesize
+       \centering
+
+       \resizebox{\columnwidth}{!}{
+       \begin{tabular}{lrrr}
+               \hline
+               Benchmark & \# Executions & \# Feasible & Total Time (s) \\
+               \hline
+               Chase-Lev Deque & 1,365 & 232 & 0.15 \\
+               SPSC Queue & 19 & 15 & 0.01 \\
+               RCU & 1269 & 756 & 0.11 \\ 
+               Lockfree Hashtable & 30,941 & 25,731 & 11.39 \\ 
+               MCS Lock & 19,501 & 13,546 & 2.62 \\
+               MPMC Queue & 170,220 & 93,224 & 45.63 \\ % 1r2w
+               M\&S Queue & 168 & 114 & 0.05 \\
+               Linux RW Lock & 148,053 & 405 & 13.06 \\
+               % Results from: 2014-03-25-13:26
+               % Flags: -y -m 2 -u 3
+               \hline
+       \end{tabular}
+       }
+\vspace{-.1cm}
+       \caption{\label{fig:benchmark_results} Benchmark results}
+\vspace{-.3cm}
+}
+\end{figure}
+
+\mysubsection{Performance}\label{sec:performance} 
+
+Figure~\ref{fig:benchmark_results} presents performance results for
+\TOOL on our benchmark set.  We list the number of
+the total executions that \cdschecker has explored, the number of the feasible
+executions that we checked the specification for, and the time the benchmark
+took to complete.  All of our benchmarks complete within one minute
+and most take less than 3 seconds to complete.
+
+\mysubsection{Finding Bugs}\label{sec:findbugs}
+
+\begin{figure}[!htb]
+\vspace{-.2cm}
+{\footnotesize
+       \centering
+       
+       \resizebox{\columnwidth}{!}{
+       \begin{tabular}{l|ccccc|c}
+               \hline
+               Benchmark & \# Injection & \# DR & \# UL & \# Correctness & \# Sync & Rate\\
+               \hline
+               Chase-Lev Deque & 10 & 0 & 2 & 3 & 2 & 70\%\\
+               SPSC Queue & 2 & 2 & 0 & 0 & 0 & 100\%\\
+               RCU & 3 & 0 & 0 & 1 & 2 & 100\%\\
+               Lockfree Hashtable & 5 & 0 & 0 & 0 & 2 & 40\%\\
+               MCS Lock & 4 & 0 & 0 & 0 & 4 & 100\%\\
+               MPMC Queue & 6 & 0 & 0 & 0 & 2 & 33\%\\ 
+               M\&S Queue & 11 & 0 & 6 & 3 & 0 & 82\%\\
+               Linux RW Lock & 8 & 0 & 0 & 0 & 8 & 100\%\\
+               \hline
+               Total & 49 & 2 & 8 & 7 & 20 & 76\%\\
+               \hline
+               
+               % Results from: 2014-03-25-17:08
+               % Flags: -y -m 2 -u 3
+       \end{tabular}
+       }
+\vspace{-.2cm}
+       \caption{\label{fig:injection_results} Bug injection detection results}
+\vspace{-.2cm}
+}
+\end{figure}
+
+The next component of the evaluation examines the effectiveness of \TOOL for finding bugs.
+
+\mypara{\bf New Bugs:} In the M\&S queue benchmark used
+in~\cite{cdschecker}, the dequeue interface does not differentiate
+between dequeuing the integer zero and returning that no item is
+available, and it passed our initial specification.  However, after
+modifying the dequeue interface to match that in the original paper,
+\TOOL is able to find a new bug that \cdschecker did not find.  The
+original test driver for this benchmark performed the enqueues first
+to make it easy to write assertions that are valid for all executions.
+\TOOL allows specification assertions to capture the behavior of the specific execution
+and thus is able to discover the given bug.
+
+\mypara {\bf Injected Bugs:} To further evaluate \TOOL,
+we injected bugs in our benchmarks by weakening the ordering
+parameter of the atomic operations. These include
+changing \code{release}, \code{acquire}, \code{acq\_rel} and
+\code{seq\_cst} to \code{relaxed}. We weakened one operation per
+each trial, and covered all of the atomic operations that our
+tests exercise.  While this injection strategy may not
+reproduce all types of errors that developers make, it does
+simulate errors that are caused by misunderstanding the
+complicated semantics of relaxed memory models.
+
+This fault injection strategy will introduce one of two types of bugs.
+The first type is a specification-independent bug, which can be
+detected by the underlying \cdschecker infrastructure which includes
+internal data races and uninitialized loads. The second type is a
+specification-dependent bug, which passes the built-in checks 
+but violates the \TOOL specification.  These include
+failed assertions and synchronization violations.  We
+classifying bugs as follows. If \cdschecker reports a data
+race or an uninitialized load, \TOOL reports the error and stops.
+If not, \TOOL continues to check the
+execution against the specification.  It first
+checks for violations of the preconditions and postconditions and then for
+violations of the synchronization specification.
+
+Figure~\ref{fig:injection_results} shows the results of the injection
+detection.  The column \textit{DR} represents data races, \textit{UL} represents
+uninitialized loads, \textit{correctness} represents a failed precondition or
+postcondition, and
+\textit{sync} represents a synchronization violation. The detection rate is the
+number of injections for which we detected a bug divided by the total
+number of injections.
+
+\mypara{\bf Linux Reader-Writer Lock:} Our initial specification for this
+benchmark did not allow \code{write\_trylock} to spuriously fail.
+However, when we checked this benchmark against that specification,
+\TOOL checker reports a correctness violation. We then analyzed the code
+and found that \code{write\_trylock} first subtracts a bias from the
+\code{lock} variable to attempt to acquire the lock, and restores that
+bias if the attempt to acquire the lock fails.  In the scenario where
+two \code{write\_trylock} are racing for the lock before the lock is
+released, one \code{write\_trylock} can first decrement the lock
+variable, the lock can be released by the original holder, and then
+the second \code{write\_trylock} can attempt to acquire the lock.
+Even though the history indicates that the lock is unlocked, it
+still holds a transient value due to the partially completed first
+\code{write\_trylock} invocation.  Thus, the second
+\code{write\_trylock} invocation will also fail.  As the second
+\code{write\_trylock} serializes after both the first unsuccessful
+\code{write\_trylock} and the \code{unlock} operation,
+the sequential specification would force it to succeed.  We then modified  
+the specification
+of \code{write\_trylock} to allow spurious failures so that our correctness
+model fits this data structure.  This shows
+\TOOL can help developers iteratively refine the
+specifications of their data structures. By analyzing the \TOOL
+diagnostic report, developers can better understand
+any inconsistencies between the specification and the
+implementation.
+
+\mypara{\bf MCS Lock:} Three of the weakened
+operations are not detected because they cause the execution
+to fail to terminate (and hit a trace bound).  We 
+reviewed the code and found that weakening any of those three 
+operations makes the lock spin forever.
+
+\mypara{\bf M\&S Queue:} Our test driver does not cause
+an enqueue or dequeue thread to help another
+enqueue thread update the tail pointer, which corresponds to two of the
+undetected injections.
+
+\mypara{\bf Lockfree Hashtable:} Our experiment only focuses on the two
+primitive methods, \code{get} and \code{put} without triggering the
+\code{resize}. We were able to successfully check all executions from a  test driver for the lockfree hash table that generates executions that have no program order preserving sequential histories.
+
+\mypara{\bf MPMC Queue:} The undetected injections in this benchmark are
+primarily due to the limitation of our test driver. One
+synchronization property of this benchmark is
+that \code{read\_consume} should synchronize with the
+next \code{write\_prepare} to ensure that a slot cannot be reused
+before the consumer has finished with the slot.  Our test driver is
+unable to reach this case so those injections are not detected.
+
+From our experiments on concurrent data structures, we can see that
+\TOOL checker can help detect incorrect memory orderings,
+help developers refine data structure specifications,
+and help determine whether strong memory orderings are really
+necessary. Since \TOOL checker is a unit testing tool, it is limited
+to small-scale tests to explore common usage scenarios of the data
+structures. As a unit testing tool, \TOOL was able to find 100\% of
+injections for many data structures and to find 76\% of the injections
+on average. For our 49 injections, 10 of them were detected by checks
+in \cdschecker, and 27 additional injections were detected by
+\TOOL. This shows that by writing specifications, we detect
+significantly more fault injections. 
diff --git a/correctness-model/writeup/example.tex b/correctness-model/writeup/example.tex
new file mode 100644 (file)
index 0000000..3ee4f3d
--- /dev/null
@@ -0,0 +1,165 @@
+\mysection{Motivating Example}
+\label{sec:example}
+
+We will use the read-copy update (RCU)~\cite{rcu} implementation in
+Figure~\ref{fig:rcuexample} as a running example.  RCU data structures
+are useful for usage scenarios with large numbers of reads and
+relatively few updates.  RCU based data structures scale to large
+numbers of readers because read operations do not contain any
+low-level store operations and thus do not generate coherence traffic to invalidate cache lines.
+Lines~\ref{line:rcuBegin} through~\ref{line:rcuEnd} contain
+the code for the RCU implementation, and
+Lines~\ref{line:testcaseBegin} through~\ref{line:testcaseEnd} show a
+test case for the implementation.
+
+The RCU implementation maintains a shared pointer
+(Line~\ref{line:rcuSharedData})
+\code{node} to reference the data shared by readers and
+updaters. A reader loads the shared pointer (Line~\ref{line:rcuReadLoad}) to read
+the shared data, while an updater allocates a new struct
+(Line~\ref{line:rcuUpdateAlloc}), loads the shared pointer
+(Line~\ref{line:rcuUpdateLoad}), and then attempts a compare and swap (CAS) operation to update the shared pointer.  This process repeats until the CAS is successful.
+
+\begin{figure}[h]
+\vspace{-.2cm}
+\begin{lstlisting}[xleftmargin=6.0ex]
+#define mo_acquire memory_order_acquire
+#define mo_acq_rel memory_order_acq_rel
+struct Node {/*@ \label{line:rcuBegin} @*/
+       int data ;
+       int version;
+};
+
+class RCU {
+       atomic<Node*> node;/*@ \label{line:rcuSharedData} @*/
+       public:
+       RCU() {
+               Node *n = new Node;
+               n->data= 0;
+               n->version = 0;
+               atomic_init(&node, n);  
+       }
+       void read(int *data, int *version) {
+               Node *res = node.load(mo_acquire);/*@ \label{line:rcuReadLoad} @*/
+               *data = res->data;
+               *version = res->version;
+       }
+       void update(int data) {
+               bool succ = false;
+               Node *newNode = new Node;/*@ \label{line:rcuUpdateAlloc} @*/
+               Node *prev = node.load(mo_acquire);/*@ \label{line:rcuUpdateLoad} @*/
+               do {
+                       newNode->data = data;
+                       newNode->version = prev->version + 1;
+                       succ = node.compare_exchange_strong(prev,/*@ \label{line:rcuUpdateCAS} @*/
+                               newNode, mo_acq_rel, mo_acquire);/*@ \label{line:rcuUpdateCASMO} @*/
+               } while (!succ);
+       }
+};/*@ \label{line:rcuEnd} @*/
+
+RCU x, y; // Define two RCU objects/*@ \label{line:testcaseBegin} @*/
+int r1, r2, v1, v2;
+void thrd_1() { // Thread 1/*@ \label{line:thrd1} @*/
+       x.update(1);
+       y.read(&r1, &v1); // r1 == 0
+}
+void thrd_2() { // Thread 2/*@ \label{line:thrd2} @*/
+       y.update(1);
+       x.read(&r2, &v2); // r2 == 0
+}/*@ \label{line:testcaseEnd} @*/
+\end{lstlisting}
+\vspace{-.2cm}
+\caption{\label{fig:rcuexample}C++11 read-copy update example}
+\vspace{-.3cm}
+\end{figure}
+
+\begin{figure}[t]
+        \centering
+\vspace{-.3cm}
+       \resizebox{\columnwidth}{!}{
+               \includegraphics[scale=0.33]{figures/rcuhistory}
+       }
+  \vspace{-.4cm}
+               \caption{\label{fig:rcuhistory}History of a possible execution of two RCU objects}
+\vspace{-.4cm}
+\end{figure}
+
+This implementation uses low-level atomic operations provided by
+C/C++ to implement the RCU mechanism. For example, in
+Line~\ref{line:rcuUpdateCAS}, the \code{update} method uses a CAS
+operation to update the \code{node}. The memory
+order parameters attached to the atomic operations ensure that memory
+accesses that were performed before the \code{update} operation must
+occur before memory accesses that were performed after the \code{read}
+operation.
+
+\mysubsection{Consistency Model}
+\label{sec:exampleMotivation}
+
+In the example code, two threads, Thread~1 and Thread~2, each update
+one of the RCU objects \code{x} and \code{y}, respectively, and then
+access the object updated by the other thread.  Under the C/C++
+memory model, this example admits an execution in which both Thread~1
+and Thread~2 read the initial value 0.
+
+Figure~\ref{fig:rcuhistory} shows a possible order for this
+execution in which the model checker processes statements in the order shown in
+the
+execution labeled Original Trace\footnote{Note that the C/C++ memory
+model does not include any notion of a trace.  We merely use the term
+trace to refer to the order in which \TOOL prints the execution.},
+which is an interleaving of the invocation and response events of
+API methods indicated by \lq\lq\_i\rq\rq and \lq\lq\_r\rq\rq,
+respectively.
+
+This trace is rather counter-intuitive because it orders 
+Thread~1's \code{update} event before Thread~2's \code{read} event,
+yet Thread~2's \code{read} event does not observe the updated value.
+However, under the C/C++11 memory model, this is allowed since a load
+is allowed to read a value that is written by an old store.
+
+It is important to note that it is impossible to produce a sequential history
+for this example that preserves program order and produces the observed
+behavior.  This means that traditional notions of correctness that relate
+concurrent executions to sequential executions that were developed for
+the SC memory model cannot directly be applied to the C/C++11 memory
+model.
+
+This example leads to the following conclusion --- if we want to
+define the behavior of concurrent executions by relating them to
+equivalent sequential histories, then we must give up on preserving
+program order.
+
+We note that for this example, if we give up on program order, we
+produce the sequential history in Figure~\ref{fig:rcuhistory}
+labeled Reordered Trace.  The data structure operations in this
+sequential history have behavior that is consistent with the observed
+behaviors in the example execution.
+
+\mysubsection{Synchronization Properties}
+
+A correct RCU data structure ensures the property that the invocation
+event of an \code{update} operation happens-before the response event
+of the subsequent
+\code{read} operation. Informally, all operations that appear before the \code{update} operation must appear to occur before the operations that appear after the \code{read} operation.  While these
+semantics follow naturally for SC, for relaxed memory models we must
+ensure that neither the compiler nor the processor performs
+reorderings that violate these semantics. Therefore, when a reader
+reads the fields of the
+\code{node}, 
+data races are eliminated since the \code{read} operation synchronizes with the \code{update} operation.
+
+
+In the C/C++11 memory model, the transitive closure of
+\textit{sequence-before} and \textit{synchronizes-with} relations form the
+\textit{happens-before} relation in the absence of operations with the \code{consume} memory order.  Since every time an \code{update} operation finishes, a CAS operation to
+\code{node} with release semantics is executed, and the subsequent \code{read}
+loads the \code{node} reference with acquire semantics, the \code{read} operation synchronizes
+with the \code{update} operation, providing the necessary synchronization properties.
+Some RCU implementations may use consume semantics instead of acquire semantics,
+however we do not use consume for the following two reasons: (1) most existing
+C/C++ compilers do not support consume semantics and thus acquire does not
+involve extra overhead and (2) using consume semantics provides a more complex interface to 
+clients that may require them to explicitly declare dependences throughout the code.
+
+
diff --git a/correctness-model/writeup/figures/CVS/Entries b/correctness-model/writeup/figures/CVS/Entries
new file mode 100644 (file)
index 0000000..998018a
--- /dev/null
@@ -0,0 +1,42 @@
+/fence_sw.dot/1.1/Wed Jan 14 22:53:32 2015//
+/fence_sw2.dot/1.1/Wed Jan 14 22:53:32 2015//
+/fence_sw_r_collapse.dot/1.1/Wed Jan 14 22:53:32 2015//
+/fence_sw_r_collapse2.dot/1.1/Wed Jan 14 22:53:32 2015//
+/fence_sw_w_collapse.dot/1.1/Wed Jan 14 22:53:32 2015//
+/fence_sw_w_collapse2.dot/1.1/Wed Jan 14 22:53:32 2015//
+/ff_sc_rf.dot/1.1/Wed Jan 14 22:53:32 2015//
+/ff_sc_rf2.dot/1.1/Wed Jan 14 22:53:32 2015//
+/fw_sc_rf.dot/1.1/Wed Jan 14 22:53:32 2015//
+/fw_sc_rf2.dot/1.1/Wed Jan 14 22:53:32 2015//
+/lockhistory.pdf/1.1/Wed Jan 14 22:53:32 2015/-kb/
+/release_seq.pdf/1.1/Wed Jan 14 22:53:32 2015/-kb/
+/rmw_atomicity.dot/1.1/Wed Jan 14 22:53:32 2015//
+/rmw_atomicity2.dot/1.1/Wed Jan 14 22:53:32 2015//
+/rmw_mo.dot/1.1/Wed Jan 14 22:53:32 2015//
+/rmw_mo2.dot/1.1/Wed Jan 14 22:53:32 2015//
+/rr_mo.dot/1.1/Wed Jan 14 22:53:32 2015//
+/rr_mo2.dot/1.1/Wed Jan 14 22:53:32 2015//
+/rw_mo.dot/1.1/Wed Jan 14 22:53:32 2015//
+/rw_mo2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/sc_mo.dot/1.1/Wed Jan 14 22:53:33 2015//
+/sc_mo2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/sc_wr_mo.dot/1.1/Wed Jan 14 22:53:33 2015//
+/sc_wr_mo2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/specdesign.pdf/1.1/Wed Jan 14 22:53:33 2015/-kb/
+/specworkflow.pdf/1.1/Wed Jan 14 22:53:33 2015/-kb/
+/wf_sc_rf.dot/1.1/Wed Jan 14 22:53:33 2015//
+/wf_sc_rf2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/workflow.pdf/1.1/Wed Jan 14 22:53:33 2015/-kb/
+/wr_mo.dot/1.1/Wed Jan 14 22:53:33 2015//
+/wr_mo2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/ww_mo.dot/1.1/Wed Jan 14 22:53:33 2015//
+/ww_mo2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/ww_sc_fence_first_collapse.dot/1.1/Wed Jan 14 22:53:33 2015//
+/ww_sc_fence_first_collapse2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/ww_sc_fence_mo.dot/1.1/Wed Jan 14 22:53:33 2015//
+/ww_sc_fence_mo2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/ww_sc_fence_second_collapse.dot/1.1/Wed Jan 14 22:53:33 2015//
+/ww_sc_fence_second_collapse2.dot/1.1/Wed Jan 14 22:53:33 2015//
+/rcuhistory.odg/1.2/Wed Jan 21 22:50:28 2015//
+/rcuhistory.pdf/1.4/Wed Jan 21 22:50:15 2015/-kb/
+D
diff --git a/correctness-model/writeup/figures/CVS/Repository b/correctness-model/writeup/figures/CVS/Repository
new file mode 100644 (file)
index 0000000..aadc881
--- /dev/null
@@ -0,0 +1 @@
+Papers/15/issta.cdsspec/figures
diff --git a/correctness-model/writeup/figures/CVS/Root b/correctness-model/writeup/figures/CVS/Root
new file mode 100644 (file)
index 0000000..cd8b2f1
--- /dev/null
@@ -0,0 +1 @@
+:ext:peizhaoo@plrg.eecs.uci.edu:/home/cvs/Papers
diff --git a/correctness-model/writeup/figures/fence_sw.dot b/correctness-model/writeup/figures/fence_sw.dot
new file mode 100644 (file)
index 0000000..1d4bbd4
--- /dev/null
@@ -0,0 +1,20 @@
+digraph fence_sw {
+margin=0
+ranksep=.3;
+
+N1 [label="A: fence(release)", shape=none];
+N2 [label="X: v.store(1)", shape=none];
+N3 [label="Y: v.store(2)", shape=none];
+N4 [label="Z: v.load()", shape=none];
+N5 [label="B: fence(acquire)", shape=none];
+N6 [style=invis, shape=point];
+
+//N1 -> N5 [label="sw", color=blue, penwidth=3, constraint=false];
+N2 -> N3 [label="hrs", color="#555555"];
+N3 -> N4 [label="rf", color=red];
+N1 -> N2 [label="sb", color=blue, weight=100];
+N4 -> N5 [label="sb", color=blue, weight=100];
+N2 -> N6 [style=invis];
+N6 -> N3 [style=invis];
+{rank=same; N3 N4 N6}
+}
diff --git a/correctness-model/writeup/figures/fence_sw2.dot b/correctness-model/writeup/figures/fence_sw2.dot
new file mode 100644 (file)
index 0000000..ed4ec19
--- /dev/null
@@ -0,0 +1,14 @@
+digraph fence_sw2 {
+margin=0
+//ranksep=.3;
+
+N1 [label="A: fence(release)", shape=none];
+N2 [style=invis, shape=point];
+N3 [style=invis, shape=point];
+N4 [label="B: fence(acquire)", shape=none];
+
+N1 -> N4 [label="sw", color=blue, penwidth=3, constraint=false];
+N1 -> N2 [color=invis, weight=100];
+N3 -> N4 [color=invis, weight=100];
+{rank=same; N2 N3}
+}
diff --git a/correctness-model/writeup/figures/fence_sw_r_collapse.dot b/correctness-model/writeup/figures/fence_sw_r_collapse.dot
new file mode 100644 (file)
index 0000000..ee169e1
--- /dev/null
@@ -0,0 +1,18 @@
+digraph fence_sw_r_collpase {
+margin=0
+ranksep=.3;
+
+N1 [label="A: fence(release)", shape=none];
+N2 [label="X: v.store(1)", shape=none];
+N3 [label="Y: v.store(2)", shape=none];
+N5 [label="B: load(acquire)", shape=none];
+N6 [style=invis, shape=point];
+
+//N1 -> N5 [label="sw", color=blue, penwidth=3, constraint=false];
+N2 -> N3 [label="hrs", color="#555555"];
+N3 -> N5 [label="rf", color=red];
+N1 -> N2 [label="sb", color=blue, weight=100];
+N2 -> N6 [style=invis];
+N6 -> N3 [style=invis];
+{rank=same; N3 N5 N6}
+}
diff --git a/correctness-model/writeup/figures/fence_sw_r_collapse2.dot b/correctness-model/writeup/figures/fence_sw_r_collapse2.dot
new file mode 100644 (file)
index 0000000..6cc0981
--- /dev/null
@@ -0,0 +1,14 @@
+digraph fence_sw_r_collpase2 {
+margin=0
+//ranksep=.3;
+
+N1 [label="A: fence(release)", shape=none];
+N2 [style=invis, shape=point];
+N3 [style=invis, shape=point];
+N4 [label="B: load(acquire)", shape=none];
+
+N1 -> N4 [label="sw", color=blue, penwidth=3, constraint=false];
+N1 -> N2 [color=invis, weight=100];
+N3 -> N4 [color=invis, weight=100];
+{rank=same; N2 N3}
+}
diff --git a/correctness-model/writeup/figures/fence_sw_w_collapse.dot b/correctness-model/writeup/figures/fence_sw_w_collapse.dot
new file mode 100644 (file)
index 0000000..3c0a864
--- /dev/null
@@ -0,0 +1,18 @@
+digraph fence_sw_w_collapse {
+margin=0
+ranksep=.3;
+
+N1 [label="A: store(release)", shape=none];
+N3 [label="Y: v.store(2)", shape=none];
+N4 [label="Z: v.load()", shape=none];
+N5 [label="B: fence(acquire)", shape=none];
+N6 [style=invis, shape=point];
+
+//N1 -> N5 [label="sw", color=blue, penwidth=3, constraint=false];
+N1 -> N3 [label="rs", color="#555555"];
+N3 -> N4 [label="rf", color=red];
+N4 -> N5 [label="sb", color=blue, weight=100];
+N1 -> N6 [style=invis];
+N6 -> N3 [style=invis];
+{rank=same; N3 N4 N6}
+}
diff --git a/correctness-model/writeup/figures/fence_sw_w_collapse2.dot b/correctness-model/writeup/figures/fence_sw_w_collapse2.dot
new file mode 100644 (file)
index 0000000..f1325f5
--- /dev/null
@@ -0,0 +1,14 @@
+digraph fence_sw_w_collapse2 {
+margin=0
+//ranksep=.3;
+
+N1 [label="A: store(release)", shape=none];
+N2 [style=invis, shape=point];
+N3 [style=invis, shape=point];
+N4 [label="B: fence(acquire)", shape=none];
+
+N1 -> N4 [label="sw", color=blue, penwidth=3, constraint=false];
+N1 -> N2 [color=invis, weight=100];
+N3 -> N4 [color=invis, weight=100];
+{rank=same; N2 N3}
+}
diff --git a/correctness-model/writeup/figures/ff_sc_rf.dot b/correctness-model/writeup/figures/ff_sc_rf.dot
new file mode 100644 (file)
index 0000000..981e3fe
--- /dev/null
@@ -0,0 +1,18 @@
+digraph ff_sc_rf {
+margin=0
+ranksep=.3;
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="X: fence(seq-cst)", shape=none];
+N3 [label="Y: fence(seq-cst)", shape=none];
+N4 [label="B: v.store(2)", shape=none];
+N5 [label="C: v.load()", shape=none];
+
+//N1 -> N4 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+N2 -> N3 [label="sc", color=purple];
+N1 -> N2 [label="sb", color=blue, weight=100];
+N3 -> N5 [label="sb", color=blue, weight=100];
+N4 -> N5 [label="rf", color=red];
+N2 -> N4 [style=invis];
+{rank=same; N4 N5}
+}
diff --git a/correctness-model/writeup/figures/ff_sc_rf2.dot b/correctness-model/writeup/figures/ff_sc_rf2.dot
new file mode 100644 (file)
index 0000000..40f84ce
--- /dev/null
@@ -0,0 +1,18 @@
+digraph ff_sc_rf2 {
+margin=0
+//ranksep=.3;
+
+N1 [label="A: v.store(1)", shape=none];
+//N2 [label="X: fence(seq-cst)", shape=none];
+//N3 [label="Y: fence(seq-cst)", shape=none];
+N4 [label="B: v.store(2)", shape=none];
+//N5 [label="C: v.load()", shape=none];
+
+N1 -> N4 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+//N2 -> N3 [label="sc", color=purple];
+//N1 -> N2 [label="sb", color=blue, weight=100];
+//N3 -> N5 [label="sb", color=blue, weight=100];
+//N4 -> N5 [label="rf", color=red, constraint=false];
+//N2 -> N4 [style=invis];
+//{rank=same; N2 N3}
+}
diff --git a/correctness-model/writeup/figures/fw_sc_rf.dot b/correctness-model/writeup/figures/fw_sc_rf.dot
new file mode 100644 (file)
index 0000000..68ead64
--- /dev/null
@@ -0,0 +1,16 @@
+digraph fw_sc_rf {
+margin=0
+ranksep=.3;
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="X: fence(seq-cst)", shape=none];
+N3 [label="B: v.store(2)", shape=none];
+N4 [label="Y: v.load(seq-cst)", shape=none];
+
+//N1 -> N3 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+N1 -> N2 [label="sb", color=blue];
+N2 -> N4 [label="sc", color=purple];
+N2 -> N3 [style=invis];
+N3 -> N4 [label="rf", color=red];
+{rank=same; N3 N4}
+}
diff --git a/correctness-model/writeup/figures/fw_sc_rf2.dot b/correctness-model/writeup/figures/fw_sc_rf2.dot
new file mode 100644 (file)
index 0000000..6f947b1
--- /dev/null
@@ -0,0 +1,16 @@
+digraph fw_sc_rf2 {
+margin=0
+//ranksep=.3;
+
+N1 [label="A: v.store(1)", shape=none];
+//N2 [style=invis, shape=dot];
+N3 [label="B: v.store(2)", shape=none];
+//N4 [style=invis, shape=dot];
+
+N1 -> N3 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+//N1 -> N2 [label="sb", color=blue];
+//N2 -> N4 [label="sc", color=purple];
+//N2 -> N3 [style=invis];
+//N3 -> N4 [label="rf", color=red];
+//{rank=same; N3 N4}
+}
diff --git a/correctness-model/writeup/figures/lockhistory.pdf b/correctness-model/writeup/figures/lockhistory.pdf
new file mode 100644 (file)
index 0000000..3563fea
Binary files /dev/null and b/correctness-model/writeup/figures/lockhistory.pdf differ
diff --git a/correctness-model/writeup/figures/rcuhistory.odg b/correctness-model/writeup/figures/rcuhistory.odg
new file mode 100644 (file)
index 0000000..4575354
Binary files /dev/null and b/correctness-model/writeup/figures/rcuhistory.odg differ
diff --git a/correctness-model/writeup/figures/rcuhistory.pdf b/correctness-model/writeup/figures/rcuhistory.pdf
new file mode 100644 (file)
index 0000000..07df89c
Binary files /dev/null and b/correctness-model/writeup/figures/rcuhistory.pdf differ
diff --git a/correctness-model/writeup/figures/release_seq.pdf b/correctness-model/writeup/figures/release_seq.pdf
new file mode 100644 (file)
index 0000000..5a264d5
--- /dev/null
@@ -0,0 +1,344 @@
+%PDF-1.5\r%âãÏÓ\r
+1 0 obj\r<</Metadata 2 0 R/OCProperties<</D<</ON[6 0 R]/Order 7 0 R/RBGroups[]>>/OCGs[6 0 R]>>/Pages 3 0 R/Type/Catalog>>\rendobj\r2 0 obj\r<</Length 21486/Subtype/XML/Type/Metadata>>stream\r
+<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
+<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.2.2-c063 53.352624, 2008/07/30-18:05:41        ">
+   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
+      <rdf:Description rdf:about=""
+            xmlns:xmp="http://ns.adobe.com/xap/1.0/"
+            xmlns:xmpGImg="http://ns.adobe.com/xap/1.0/g/img/">
+         <xmp:CreatorTool>Adobe Illustrator CS4</xmp:CreatorTool>
+         <xmp:CreateDate>2012-11-08T19:47:19-08:00</xmp:CreateDate>
+         <xmp:MetadataDate>2012-11-08T19:47:19-08:00</xmp:MetadataDate>
+         <xmp:ModifyDate>2012-11-08T19:47:19-08:00</xmp:ModifyDate>
+         <xmp:Thumbnails>
+            <rdf:Alt>
+               <rdf:li rdf:parseType="Resource">
+                  <xmpGImg:width>256</xmpGImg:width>
+                  <xmpGImg:height>120</xmpGImg:height>
+                  <xmpGImg:format>JPEG</xmpGImg:format>
+                  <xmpGImg:image>/9j/4AAQSkZJRgABAgEASABIAAD/7QAsUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA&#xA;AQBIAAAAAQAB/+4ADkFkb2JlAGTAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoK&#xA;DBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8f&#xA;Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAeAEAAwER&#xA;AAIRAQMRAf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA&#xA;AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB&#xA;UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE&#xA;1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ&#xA;qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy&#xA;obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp&#xA;0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo&#xA;+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A9LXvmXQ7HXdN0G6u1i1b&#xA;WEnk021IYmVbVVeajAFRxVwaMRXelaHFVlz5v8p2qSPc63YQJC4ilaS6hQJI0ssARizCjGa2ljof&#xA;2kZeqmiqAs/zM/Lu8svrtv5m0trURpM8hvIE4RyOI0aQMyslXYL8QHxGnXFVSL8wvJc+oWGn2urQ&#xA;3dxqbBLJrXlcROxSWQL60IeJSUtpD8TD7OKrta/MDyPoi3/6V16xtZNMUPf27zxmeLlE06KYFJl5&#xA;vEhZFC8mH2QcVVW87eTUleF9e09Jo/W9SJ7qFXT6tH60/JSwZfSiPOSo+FdzQYqvsfOHlXUNQj0/&#xA;T9Xs7y9ki9dILeeOZvT4o4b4C1OSSKy1+0u4qK4qm0jrGjOxAVAWYkgAAb9Ttirxz8r/AM/L7zl5&#xA;qk0a40uygilmeKD6netdTwCG0SaRpl9JEkh9XnGLiNghbiqhh+8ZV7JirTuqIzsaKoJY+AGKsd0X&#xA;8xvJGs6KNbstXhXSyzILm652Y5R2/wBcb4bpYW2tgZq0/u/j+zvird7+Y3kCw1E6be+Y9Ntr5PVE&#xA;kEt1CjI0HH1Fkq1EZfUHwtQ/ccVXzfmD5EheSN/MOnGaKL13t0uoXm9P0xMGESMztWNg4oNwQR1x&#xA;VdD548qyWGoahNqC2FnpM62upTakkmniCV1jZBJ9cWAqHE6cW6NyFCcVUG/Mr8vklkjk8xafGsSR&#xA;u873MawfvnmjRROxETOXtJRwDchxNRiqtcef/IttFLLP5i0yKOBTJMzXkACqspgZj8ewEymP/WHH&#xA;riqO8v8AmDRvMWjWmtaLdJe6Xep6ltcpUBlBKnZgrKQwIIIqDscVTDFXYq7FXYq7FXYq7FXYq7FX&#xA;Yq7FXYq7FXYqwrzj+U3lvzZrUetajPdxahBAlravC8bRRxr64lH1eeOaCX10umjlEyOCoAAHxVVQ&#xA;up/kt5avbrUbiK9vrBtUv01S7+rNb1FxEVaMwySwSywcJPVcGF1blLJU0ICqpQP+ccPJR09tOm1D&#xA;VJrIxpEkLS268FQ2X2Wjt0f4o9KtozUn4VqKMzMVUVon5H2Og2DWuj61dxyQXLanpl7cpFcTxak9&#xA;pdWj3E7FVW4Qrd8/T4r8S1LHkcVVPPP5CeTfOd1e3Op3WowS39wbm5+qTRxqxNtb2vplWicMgFlE&#xA;4DVIcVB7Yqh3/wCcfPKbalcXy6rqy/WZ7y5ltGmt5bUvfxzRuDBNBLGyx/XJjGGBoXatQxGKofS/&#xA;yf8ALHknW7PVbfVtVuDcyNEVuHF1cGcW04WRJFVZFUJLcySKFartyHEA1lEkXIDiEdz12sDf4kMJ&#xA;z4RbPbfRbe5hWa31i9mhb7MkdyGU022IGZEdaCLEYfJYkSFg2FT/AA5/2tNQ/wCR/wDzbh/N/wBC&#xA;HyZUgPMHkj9L6DqWlfpe+i/SFrPa+o8nqqvrRtHyaP4OYHL7PIV8cv0vaPhZY5OCB4JA8q5G+fRB&#xA;CRaNpGmflj5YdNb8w6prEFwEg5XhadEdUYcbdArGFWX9lpCNuuV9udtQzS8Q44YhZ+gbm/5x5E+d&#xA;BpzZ44Y3JLvLX5C+QYfKUOmp9dl066exvQtz9VjuB9V5ssbvbwxNxlimeOVCSKM5HF3d218JcQB7&#xA;26E+KIPeiZvyH0KbVm1eTXtX/STTi7M6GwjX1xLb3HqiBLNYA7T2UMjt6dXK/FUVGSZJLqn/ADjn&#xA;5RsAmsaXc6qdQ05LZrOAPFcQ87K3itYJHtisXqmKOItxDqzcnA+0FwSNC2zFDilVge/l+Ps79k30&#xA;jynpM2manDfarqt9pOs3tpq7NcwWzyreWl2Ll3e5sofT9NzBDEY5BWNY+IIGy1DOKsgj8eVtOWRx&#xA;yMckZRI8v0iwkifkZ+Wum6DILXzPq0NnJLYCS5gu7eZ5G055XtICBBIJQrSikfE/3aUHw72RmJcj&#xA;axnGW4Nquif848eTOaapY3OuaZc26tFpi3MtuTAoooeOF4pQKwqsP7wciigsOfx5JkzH8sfIF75G&#xA;8tWPl5dWF/YWIlEYNuImb1ZWkqzc3+zzptSvXFWRX9jrE0/qWep/VUoB6LQJKtR3qSrb998VRF42&#xA;pR2oNlHFcXS0qkztCjD9r4lSUg+Hw4qt025vriJje2ZspVbjw9RJVYUHxKy70/1gD7YqusNT07UI&#xA;jLY3MV1Gp4s0Tq9D4Gh2PscVROKuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxVJ/MpMKabfjf&#xA;6nf25KnoRck2TE/6q3Rb6MzNHvxx/nQP+x9f+9pBRdxo9pLM1xHztbpqFri3bgzEdOY3ST/Zqc18&#xA;sQJsbHy/G/xa5YYk2Nj3j8b/ABWi11mP4Y7+OROzT2/KT6TFJCv/AAuDhmOvzH6iEcMx/F8x+oh5&#xA;/rf5vWumebn8sXy34kiuYLSXUbK0thArz/UwGLT3Mz8UbVLcNSGvxbVoTjwzPM/IfrteCZ5y+Q/X&#xA;ac+S9U8o+edIuL1LCeZQYo5RqojklKXNtDfQunF5kRJIbqNwqlaHYqCMB08DzHF790HTQP1Di9+/&#xA;4+DNsub3Yq7FWPeYIbrTW/SeiRM+p3MixPYKCYbpyNjLTaJlVa+t4CjcvhGVmG9hzMeoBjwZd49D&#xA;/FH3d4/on4UbXaUtlq9up1GJU1y2VUvgim3uInP8rI5cIf2WVyrDocjwxnzG/wBrjanQiJBNEHlI&#xA;dfcefvGxHUIto9XsAGic6lbD7UMnFbkD/IccEeng9D/lHGpx5eofb+Pxbi1OHL1D7f2/H5sb/MXz&#xA;b5s0/wAtwah5IsU1W/aeZLi3ltri4KJBZXNxwaKF4pEkeeCOEcujOBSpGWQmJCw2QmJCwk/lnzv+&#xA;aN15n0zStZ0JYbOSS4hv7yOxvIo2WGXUEFwk0kjxQLS0taRycmk9fkpouSZvUMVdiqFOlab9fXUP&#xA;qsQvlBUXIUCTidiCw3I+eKoW9uPMFte+pBbRX2nPxDRRt6VzF2ZhzPpyjvSqn54qmmKuxV2KuxV2&#xA;KuxV2KuxV2KuxV2KuxV2KuxV2KoTV9OTUtKvNPkcxpdwyQGRd2X1FK8hXutajLcGU45xmP4SD8lK&#xA;l5f1KTUtGtbuZQl0ycLyJdxHcxExzx/7CVGX6MnqsIx5DEfT084neJ+IooCYZjpS648teXLi7a8u&#xA;NKs5rt3Ej3ElvE0hdTEVYuVLFgbWGh/4rT+VaKqmk6Jo2j2zWukWFtp1s7tK8FpCkCGRqcnKxhQW&#xA;NBU4qjcVdirsVY1qPmLWW8m69rWkWYub60gvpNDtQrym5e2jYQgxpxdvVlTZVNSpFN8VSjyPYeb9&#xA;W0W6vvNlyYfMMepXyadcQWv1P6vaxTGGJEjcu0sEwi9X96zVDjf4VbIShfvcjBqTjsEcUDzieR/U&#xA;e4j7rDKLHV5RdLp2qItvqBBMLLX0LhRuWhY96fajPxL7r8RYz3o82eXTDh48Z4ode+P9b9EuR8js&#xA;u1C2mglOpWKFp1A+tW6/8fEajoO3qL+we/2TsaiE4kHijz6+f7e75OtyRIPFHn18/wBvd8kdbXEF&#xA;zbx3EDiSGZQ8bjoVYVBy2MgRY5NsZCQsciqYWTsVdirsVS/VtGh1ERSCWS1vbeptbyBuMkZalRQ1&#xA;V1ag5KwIOKqzXkNlDapqFzGJ5mSBZSPTWWcrWiqS1OXE0FfbFUVirsVdirsVdirsVdirsVdirsVd&#xA;irsVdirsVSOz/wBxvmS6sj8NrqoN7Z+AuEAS6jHYchwlUdSTIe2ZuT95hEv4oek+7+E/fHy9IR1T&#xA;zMJLsVdirsVdiqnc3ENtby3E7cIYUaSVzU0VBVjt4AYq61jto7aKO2RY7dVAhjjUKoWmwVRQAUxV&#xA;UxVQvrC0v7Zra7jEsLUNKkEMDVWVloysp3VlNQdxglEEUWzFmljlxRNH8fMd46vLPM/5o635U836&#xA;Zot5DLJoSThLzWbmFozLFIvEBXoEf0S3JnWnKlKDcthZNRKEgDy73r9B2Bi1mlnliQM3D6YRN0R5&#xA;cxxcgDy533HGgaP5w078xZYb69mu9DeC4urRl/dw83kXkrxoFj9QGQnpv1+VOHFljnokmFE+X9r5&#xA;vgw5YZ6JJhRPl8uV7vQs2jtXYq7FXYq7FVG9srS+tZbS7iWa2mXjLE4qCMVSvSl1TTrsaXcCS8sG&#xA;Umxvz8Toq/7puD4gfYk/aGx+L7SqdYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYqluv6ZNf2A+qsI9R&#xA;tHFzp0rEhVnjB4huO/B1LRyU6ozDMnS5hCXq+iW0vcf0jmPMBBCto+qQ6pp0V7Epj58llhf7cUsb&#xA;FJYnp+1HIrK3uMhqMJxTMT/aDuD8RuoKMylLsVdirsVUNQtFvbC5s2PFbmJ4WbrQSKVrSo8cVYZ5&#xA;28k6vqs+kz2kNlqg06yurT6tqLrCkdzObdodQg52mpRevB9XYJzhI+M9qhlUm89fln5z8xarqUY1&#xA;ZZ/LOqNYCTSp7q5hWJEntnv+KxIwfnFp6JEoKbzTNVa/Gqx3Q/yl/OSzuTe6r5ij1O4kitYbqNNW&#xA;1S19WK3lleSL1kjeSP1jMsvqLuhUxqBG5oqj/Lnkj8xPLfka98kC3fWZLqK1GnalLfyfo6142lvF&#xA;cRSSC4ttRjj9eGV0SCMrxdQKfEAkJjIxNjYsR1X8kvzcljsjq/mS0uZm0270e6mn1jUoVumvrdI4&#xA;YgiwcI0imjV2Vf8AejgOY+I0BIDKMJTugT1P62d/l5pF75f1+K8uTaSXOp2lvputVvI/rK3FpNqM&#xA;8l8yH7aXDSwqiA81D/EBwOQ8aF1Ycfx4XVi/exf/AJUx+daSae8nme31JNPMFxFFf6lqzE3P6Okt&#xA;p29ZOMyD6xNI6GN0Yq1GNFRRY2qkH5T/APOQi29pH/jaOKRWtzdTG+1CdlMQPMxh0VZOTcnKuOLC&#xA;TgaCGJsVZZ+T3kTzr5X8webLjzBKJLTVmsZrPjf3GogyxQtFOxluljm5fCtSy7jiBsuKvUcVdirs&#xA;VSvT7nVE1K4sL+MyJ8U9lfIlEaIt/dSU2WSPkB/lLv2bFU0xV2KuxV2KuxV2KuxV2KuxV2KuxV2K&#xA;uxVj1/8A7gdWfVl20jUGRdXH7ME4ASK89kKhY5j2AVtgrnNhi/f4/D/ykPp8xzMff1j8RuTFHJkO&#xA;a9LsVdirsVdiqWaKl/DLqFtdmSSOO5eSznkJblDP+941O/7t2ZAPADFUzxV2KuxVTuLeC5geC4jW&#xA;aCUFZInAZWU9QQdjgItlCZiQYmiElmW50eNkuFfUdCP2i4M09sv+WDyaaIeO7r35DcVkcPPeLmmM&#xA;NTttHJ3coy/RGX+xPSuoqLRtIkgSbTj9VjkUPFLYyenGwIqr8UPpP7clODwY/wAO3u/FOrnpREkU&#xA;YEd232frC4nWbPc01K3HYBYrkf8AEYpP+Ep74+uP9Ifb+o/Yx9cf6Q+R/UfsRdlf2t7EZbd+QU8X&#xA;Ugq6MOqujAMrDwIrlkJiQsNkMgkLDzi9/wCcgfKNjqmoWF3puqRJpzXiTXxitzAxsRe8+HGcyH1D&#xA;pVwqVQbr8XEHJM2deWvMFtr+l/pCCCa14z3NpNbXAQSxz2dw9tMjek8sZ4yRMKq5B8cVTTFXGtDT&#xA;Y9id8VSzQtSubqKa2vkEep2L+ldqoIRqiqSx1r8Ei7jw3HbFUzxV2KuxV2KuxV2KuxV2KuxV2Kux&#xA;V2KrZI45Y3ilQSRyAq6MAVZSKEEHqDhBINjmqQaZNJoV5Fol45bT524aHeOanZS31OVj1dFUmNj9&#xA;pNjVlLNn5ojPE5Y/WPrH+/Hkf4h0O/I0ByZDmvS7FXYq7FUv12/u9PsDewRCaO3dXvI6Eubcf3pj&#xA;oftqPip3pTviqOilimiSWJg8Uih43U1DKwqCD7jFV2KuxV2Kpb5l1+z8veXtS129SSS00u2lu7iO&#xA;EKZGSFC7BA7IvKg2qwxVjHkzWNU1jTLrX9N0ttNhN/e2z6JNPG/rC0uHt5J1aOscE7SRPVAzIxH2&#xA;t+eVmJG4+TmxzxyARy9OUuo8j3x+0dLHpZfpup2moQGW3Y1Rik0LgpLFINykiHdWFfu3GxGSjIFo&#xA;z4JYzUvgehHeD1/HVSv9PkaT69Y8Y9RRaAsSI5lG/pzUrUfytSq9tqgwnD+KP1ff7/xs4eTHvxR+&#xA;r7/I/jZA2nl/yhqMTXf6FsjLK0n1hZbWEyCVmmEyyfCatyup+W5r6jnfmayhMSFs8cxIWE007TNN&#xA;0yyisdNtIbGxgBENrbRrFEgJLEKiBVWpJOwybNE4q7FUFrOotpumzX3omdLejzIpowiDD1HGxqUS&#xA;rU70piqMR0kRXRgyOAysNwQdwRireKuxV2KuxV2KuxV2KuxV2KuxV2KuxVQv7C0v7OW0u4/UglFG&#xA;XcEEGqsrChVlYBlYbg7jfLMWWUJCUeYVJtK1HUdOvU0TW3MzPUaXq5UBbpQK+lNxAVLlQNxsJB8S&#xA;ftKmXnxQyR8XFt/Oj/N8x3w+2PI9DIMgzAS7FXYq7FUvudWjtNTtrGeIxw3alba6qOBmXf0T/KxX&#xA;dfHcdt1UwxV2KuxVRvLOzvbSazvYI7m0uEMc9vMiyRyIwoyujAqykdQcVdaWdnZw+jaQR28PN5PS&#xA;iRUXnK5kkbioA5O7szHuSTiqF1HSfXmW9tJfqmpRrxS5A5K6AkiOZKr6iVJ2qCKniVJyEoXuObk4&#xA;dRwjgkOLGend5xPQ/YeoLWnav687WV3F9U1ONeT2xPJXQGhkgei+oladgVqOQUnGM72PNObTcI44&#xA;nixnr3eUh0P2HoSgtS1TTdE1JL66uorex1AGO4aR1UCaJSUk3PdFKN7hBlOTJHHKyaEvv/G3ydXl&#xA;mMU7kaEufv7/AJbfJObS6t7y1hu7ZxJb3EaywyCoDI4DK2/iDl8ZCQBHIuRGQkARyKrkmTsVcyqy&#xA;lWAKkUIO4IOKoWwksED2FmVUaeEgaBaj0x6asi79uBGKorFXYq7FXYq7FXYq7FXYq7FXYq7FXYq7&#xA;FUPqGn2eoWctlexCa2mFJIzUdDUEEUKspAKsDUHcb5ZiyyxyEomiFSZNRvNAYW+syGfSSQttrTfa&#xA;jqdo72gHH/Jn+yej8WoXzDijn3xisnWHf5w/4nmP4bH0jkyHNel2KuxVTntre4QR3ESSoGVwrqGA&#xA;ZCGVqHurCoxVCjWLYasdLmVoLhkEls0lAk6gfH6RB3KftKd+/TfFUdirsVS3zLr9n5e8valr18sj&#xA;2el20t3cJCA0jJChdggYqpYgbVI+eKpH/wArR8q2+l3Ooaw82i/UruawvbW8j5zRXMFq16Y2+qm5&#xA;Q8rZPUQqx5VCj4yFxVK5/wA9vINtc3trdPew3VnfnTRAbOd3nkFz9T5wemrh0M6yIo+23pycVPHF&#xA;Ut8zfmF5e83XK+T/AC5qL2mvXaxz6Rq1xZ3UdtIT9Yr9Uugq0cpaS8ZB8DrUIXPILVmgZRoc3Zdk&#xA;6vFgzCeUGWPrEdfeDsR5d9MDm1PQND8l6t5Q8+NcJrHlv1LvSZbS1uZpnt5ObM8QaOPnB6kThpXK&#xA;xbgcwRmEdF4mPgnzHIs/a38pr8oy4SQZDcEUYyG3u3Fcj0eg+Xvzl8nRaba6bZRX18mn/o2wluor&#xA;YxRFbwWsNtcqLhoX9CRrxODcasAzKCtCc7FDhgI9wDpsMOGAj3ABlHmH8y/JXl3WY9G1jUGtdQli&#xA;juFj+r3MiCKVpFVmljjeJf8AeeVjyYUVGY/CpOWNiUWH55/lxc2tjPPe3GnPqFvb3cMF7Z3UTeld&#xA;AmNuYjaFlorksjlaI7V4oxCq0/nt+XDajpNhbXlxdSaverpsUkdpcLFDcuXVY7h5UjEb84+PA/GK&#xA;glePxYqzSDTRDq15frJUXcUEbQ0pRoTJV+Vd+SyKOn7OKozFXYq7FXYq7FXYq7FXYq7FXYq7FXYq&#xA;7FXYq0yq6lWAZWFGU7gg9jhBpUgGmaloR5aKn1vSur6MzBWhA/5YnYhVH/FLkJ/KyAUOd40M/wDe&#xA;+mf8/v8A64/3w37xJHJNNM1fT9TieSzl5tE3p3ELApLE9K8JY2AdGpvRh036ZjZsE8ZqQ58u4+48&#xA;ioKMylLsVUri0tbgxG4hSUwuJYS6huEi9HWvQjxxVA3uttYX6xXlq6WMvFYdQSskYkJpwmVRyj36&#xA;Mar4kYqmeKoPWNI07WdJvNJ1KH6xp+oQyW13ByZOcUqlHXkhVlqp6qQcVSWP8tfJa6XNpclg11ZT&#xA;38eqzJd3FzdM17CyMkxknkkkrWFajlRtwQQTVVLH/JL8spLiK6k0h5LyEMI7t7y9a4DNdNemQzGb&#xA;1DJ9ZkaT1C3Kp64qqj8o/J9vIlxpS3WlahBJFLZ30FxJO9sYROqJBFeG6t44wl7OojEXAczQA0IV&#xA;QUn5D/ltcz315qNjPf6pqgYarqT3dzBPdB+QcSC1e3iCvy+JERUO3w7Ciqin5V+VPL1/LdWemTSa&#xA;LcJaC8tIp7qeRZNPlhls5WSR5ZHS2+qosaRMoVfh9NwfhhKRHucrDihkFXw5PP6T8f4T79j3jqaX&#xA;P5ZeQfMNlp0+qQtrzW0FlHDqdxcyvLMLAS+hLI8TorvW6lLNT4ixr2pIG+TjzhKBMZCiEvtv+cff&#xA;yhtmdodApzWJGVru9dSsI4x/C0xGyVT3Qsp+FmBLFdD+Q35ZWzaW1hpstj+h7qC9s0hurkx+tbuW&#xA;UyRSSSRyEhijMy8uPw1oBirL7H6++uanLNzWzRbeC1RieDFFaSSRB7mYIT/k07YqmWKuxV2KuxV2&#xA;KuxV2KuxV2KuxV2KuxV2KuxVgv5o+UvOfmOLTovLOrPpLQ/WUvZlvLm1HCeH00ZY7ZOUskbHnHyk&#xA;VVI3V67Kr/yr8qedfL+mXo84a42t6pdTh45BNNLDHFwDlEWULxInklAp/usIO1MVZJqnl+yvplu1&#xA;Z7PU4l4Q6jbEJOq1rwNQyyJX9iRWXvSuZOHVSgOH6oH+E8v2HzFFBCEXVtZ0v4Nbt/rNsOmrWMbs&#xA;v/Pa2HqSx/6yF16klBtlpwY8u+I1L+bI/dLYH48J6DiW05tLy0vLdLm0njubaUVjniZXRh0qrKSD&#xA;mJPHKB4ZAgjoUquQV2KpfqttrDmKbS7tIZYuXK2nTnBKDTZitJEIpsyn5qcVVn1CK0sY7nVJIrIk&#xA;IJi0g9NZGoOIkYJX4tgaDFUSjq6h0IZWAKsDUEHoQcVbxV2KuxV2KsN8yeYvK/lzXLS2TWbTTtf1&#xA;eaKOHRJXLfXZLlzFG5gjDyR83Ur9YC8RT4+VKZWYVuHMhqRKIhlFxHI/xR93eP6J+BiyTTtXgvHe&#xA;3ZHtr6EVnspqCRQTQMKEq6Hs6kjt1BGSjO/e15tMYAS+qB5SHL9h8jv8FLXNWlso4oLSMXGqXhKW&#xA;Vua8SRTlJIR0jjBqx+jqRknHTMVpv174q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX&#xA;YqlF55ZsZbiS8s5JdL1CU8pLuyYIXbpyliYPBMabAyRsR2pmXj1kgBGQE4DpLp7j9UfgQilL675n&#xA;0/a9s49Vtx1utP8A3UwFK/FazORQeKTMx7JkvDwZPpkYHuluP9MB98QP6S7ovT/MWi38/wBWt7oC&#xA;8AJNlMrQXIVdixt5gkoX3K0yrLpMkBZHp7xvH/TCx9q2mOY6WnRHQo6hkYUZSKgg9iDiqG0/StO0&#xA;6N4rC3S2ikcyNFGOKciADRRsvToMVQ1gPMkVwIr82l1bUP8ApcPqQSAjpWFvVU18RIPlird/5g07&#xA;T5/SvBPEKA+v9XmeHft6qIyA+xOKo6W6toYhNNKkURpSR2Crv03OKro5YpQTG6uBsSpB/VirD9R8&#xA;teTNS89af5gl1Mfp219BbW0SeCjfVY71FHplTIarqMpajfsr4GqqaeZbXUL14baxsQbpB6kGrSSC&#xA;JLVjtVeJMrttugXiw2Y0yMogt2HUSx3XI8weR9/4sdFWHVLzTnS31wqUNEh1aNeMLk7BZl39Fyff&#xA;gx6EE8cjxEbS+bkHTxyjixc+sOo/q/zh/sh1BA4k5qK0rudwPlljguxV2KuxV2KuxV2KuxV2KuxV&#xA;2KuxV2KuxV2KuxV2KuxV2KuxV2KobUNM03UYPq+oWsN3BXl6U6LItfGjA75ZizTxm4ExPkaWku/w&#xA;3Jb76Xql5ZU39F5PrkJNdqrdCZ1XtxjdMyPzYl9cIy+HCf8AY0PmCim+fm+3qGisNRXqZEeWyb/V&#xA;EbC7Vj7mRca08us4fKX2+n7iu7h5jkiI+u6RqFop2D+kl0CflZPcuP8AZKMfygP0zhL48P8AuxFb&#xA;bHnDyyu1xqEVk/8Avq9rZyf8i7gRP28MH5DN0iZf1fUPnG1sJhZ6lp18nOyuobpOvKGRZBTp1UnK&#xA;MmGcNpAx94pNqk9tb3EZiuIkmjO5SRQy/ca5Wqyz0+wskaOztorZGPJkhRYwT0qQoGKqdoukx3M0&#xA;FoIEuYqG4ii4B157rzVdxyptXJGEgASNiqA0/wA5eXb+LVbiC6aO00SWaHUr25hmtbaN7VnS443E&#xA;6RxSLE0Th2RmVabnIqo3XnvyMmoPpF3rVjHcuFQwTyoqOZZprX0lZyI3k9a1mjaMEsCpBGKQSDYe&#xA;Qw6y/lf8xdL8wS+ZtL1LQdXE1raWtleeqUsF9R2aKJmkpFA9uxqjEclKD4iFzCjhyRyXzH6Hsc/a&#xA;mhz6A4aMMw9VkfVMecepG1kDz73sEn5geQ41LyeZNLRAHJZr23ApG3BzUv8Ast8LeBzNeNQ91+Z/&#xA;5c2sFrcz+ZtMW1vXCW90LuFoSWExUtKrFEVvqsqhmIUspUHltiqZ6b5m8u6pe3FlpupW17dWgrcx&#xA;W8qylPiZCGKEjkrIQy9R36jFUzxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2Ku&#xA;xV2KoC88v6Dev6l7ptrdPWvOaCOQ1NN6sp8Mvx6rLAVGUh7iQikP/g/ylv8A7hLDfrS2hH/GuWfn&#xA;9R/qk/8ATFaDv8JeXv8Alk/5KSf81Y/nsvf9gWgkY/KLySPNY80/V7gaqgQQsl1PGkfpigoI3QtX&#xA;9oOSD4Zm/wAu6nwPAscG/wDCDd+8fdSOEXanpH5R+WNN1PW74M9yuvm/+v280FgKjU5fVuFFzFbR&#xA;XhUnYK87ClP5Vpp2SR/9C6eTTLBI2paq3oWMel8TLbEPZh3lnjdvq/Mm5mleWV+XPkfgZF+HFVsv&#xA;/OPehLbWwttd1Vr20lW7S5vXguhNdxT3dxDNdAxRvLwk1KaqrInIH4qkVxVE6f8AkPothdapdw+Y&#xA;9ckudYurW+vpp5rSd2uNPnFzZuGltXI9CXdV+yRswYUxVJPK/wDzjP5dstI0JNY1C8m1LSnsLuSO&#xA;CSE2oubF55isfO3WVoZJ7yV2DnlvsV6YqyvyF+UOjeSdWuL3TL66uLeWKRI4LtllkRpmi9T98ApZ&#xA;FjtYUjUiqBT8Rrsq/wD/2Q==</xmpGImg:image>
+               </rdf:li>
+            </rdf:Alt>
+         </xmp:Thumbnails>
+      </rdf:Description>
+      <rdf:Description rdf:about=""
+            xmlns:pdf="http://ns.adobe.com/pdf/1.3/">
+         <pdf:Producer>Adobe PDF library 9.00</pdf:Producer>
+      </rdf:Description>
+      <rdf:Description rdf:about=""
+            xmlns:dc="http://purl.org/dc/elements/1.1/">
+         <dc:format>application/pdf</dc:format>
+         <dc:title>
+            <rdf:Alt>
+               <rdf:li xml:lang="x-default">release_seq_final</rdf:li>
+            </rdf:Alt>
+         </dc:title>
+      </rdf:Description>
+      <rdf:Description rdf:about=""
+            xmlns:xmpTPg="http://ns.adobe.com/xap/1.0/t/pg/"
+            xmlns:stDim="http://ns.adobe.com/xap/1.0/sType/Dimensions#"
+            xmlns:stFnt="http://ns.adobe.com/xap/1.0/sType/Font#"
+            xmlns:xmpG="http://ns.adobe.com/xap/1.0/g/">
+         <xmpTPg:NPages>1</xmpTPg:NPages>
+         <xmpTPg:HasVisibleTransparency>False</xmpTPg:HasVisibleTransparency>
+         <xmpTPg:HasVisibleOverprint>False</xmpTPg:HasVisibleOverprint>
+         <xmpTPg:MaxPageSize rdf:parseType="Resource">
+            <stDim:w>558.000000</stDim:w>
+            <stDim:h>261.000000</stDim:h>
+            <stDim:unit>Points</stDim:unit>
+         </xmpTPg:MaxPageSize>
+         <xmpTPg:Fonts>
+            <rdf:Bag>
+               <rdf:li rdf:parseType="Resource">
+                  <stFnt:fontName>TeXGyreHeros</stFnt:fontName>
+                  <stFnt:fontFamily>TeXGyreHeros</stFnt:fontFamily>
+                  <stFnt:fontType>Unknown</stFnt:fontType>
+                  <stFnt:versionString>Version 2.037;PS 2.000;hotconv 1.0.51;makeotf.lib2.0.18671</stFnt:versionString>
+                  <stFnt:composite>False</stFnt:composite>
+                  <stFnt:fontFileName>MyriadPro-Regular.otf</stFnt:fontFileName>
+               </rdf:li>
+            </rdf:Bag>
+         </xmpTPg:Fonts>
+         <xmpTPg:PlateNames>
+            <rdf:Seq>
+               <rdf:li>Cyan</rdf:li>
+               <rdf:li>Magenta</rdf:li>
+               <rdf:li>Yellow</rdf:li>
+               <rdf:li>Black</rdf:li>
+            </rdf:Seq>
+         </xmpTPg:PlateNames>
+         <xmpTPg:SwatchGroups>
+            <rdf:Seq>
+               <rdf:li rdf:parseType="Resource">
+                  <xmpG:groupName>Default Swatch Group</xmpG:groupName>
+                  <xmpG:groupType>0</xmpG:groupType>
+               </rdf:li>
+            </rdf:Seq>
+         </xmpTPg:SwatchGroups>
+      </rdf:Description>
+      <rdf:Description rdf:about=""
+            xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
+            xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#"
+            xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#">
+         <xmpMM:DocumentID>xmp.did:01801174072068118F62BC2FBF2D0DDE</xmpMM:DocumentID>
+         <xmpMM:InstanceID>uuid:b6550317-f02c-e943-99b1-a50cb06f5ab2</xmpMM:InstanceID>
+         <xmpMM:OriginalDocumentID>xmp.did:F77F11740720681184ABF8CADCB1BF49</xmpMM:OriginalDocumentID>
+         <xmpMM:RenditionClass>proof:pdf</xmpMM:RenditionClass>
+         <xmpMM:DerivedFrom rdf:parseType="Resource">
+            <stRef:instanceID>uuid:ba4dbd99-36b2-2d4a-a0d2-e8c58b81b3c8</stRef:instanceID>
+            <stRef:documentID>xmp.did:01801174072068118F62D9F7CDB3ECB2</stRef:documentID>
+            <stRef:originalDocumentID>xmp.did:F77F11740720681184ABF8CADCB1BF49</stRef:originalDocumentID>
+            <stRef:renditionClass>proof:pdf</stRef:renditionClass>
+         </xmpMM:DerivedFrom>
+         <xmpMM:History>
+            <rdf:Seq>
+               <rdf:li rdf:parseType="Resource">
+                  <stEvt:action>saved</stEvt:action>
+                  <stEvt:instanceID>xmp.iid:F77F11740720681184ABF8CADCB1BF49</stEvt:instanceID>
+                  <stEvt:when>2012-11-08T17:43:18-08:00</stEvt:when>
+                  <stEvt:softwareAgent>Adobe Illustrator CS4</stEvt:softwareAgent>
+                  <stEvt:changed>/</stEvt:changed>
+               </rdf:li>
+               <rdf:li rdf:parseType="Resource">
+                  <stEvt:action>saved</stEvt:action>
+                  <stEvt:instanceID>xmp.iid:F87F11740720681184ABF8CADCB1BF49</stEvt:instanceID>
+                  <stEvt:when>2012-11-08T18:19:13-08:00</stEvt:when>
+                  <stEvt:softwareAgent>Adobe Illustrator CS4</stEvt:softwareAgent>
+                  <stEvt:changed>/</stEvt:changed>
+               </rdf:li>
+               <rdf:li rdf:parseType="Resource">
+                  <stEvt:action>saved</stEvt:action>
+                  <stEvt:instanceID>xmp.iid:01801174072068118F62D9F7CDB3ECB2</stEvt:instanceID>
+                  <stEvt:when>2012-11-08T18:34:52-08:00</stEvt:when>
+                  <stEvt:softwareAgent>Adobe Illustrator CS4</stEvt:softwareAgent>
+                  <stEvt:changed>/</stEvt:changed>
+               </rdf:li>
+               <rdf:li rdf:parseType="Resource">
+                  <stEvt:action>saved</stEvt:action>
+                  <stEvt:instanceID>xmp.iid:01801174072068118F62BC2FBF2D0DDE</stEvt:instanceID>
+                  <stEvt:when>2012-11-08T19:47:17-08:00</stEvt:when>
+                  <stEvt:softwareAgent>Adobe Illustrator CS4</stEvt:softwareAgent>
+                  <stEvt:changed>/</stEvt:changed>
+               </rdf:li>
+            </rdf:Seq>
+         </xmpMM:History>
+      </rdf:Description>
+   </rdf:RDF>
+</x:xmpmeta>
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                                                                                                    
+                           
+<?xpacket end="w"?>\rendstream\rendobj\r3 0 obj\r<</Count 1/Kids[8 0 R]/Type/Pages>>\rendobj\r8 0 obj\r<</ArtBox[0.0 0.0 558.0 261.0]/BleedBox[0.0 0.0 558.0 261.0]/Contents 9 0 R/LastModified(D:20121108194719-08'00')/MediaBox[0.0 0.0 558.0 261.0]/Parent 3 0 R/PieceInfo<</Illustrator 10 0 R>>/Resources<</ExtGState<</GS0 11 0 R>>/Font<</T1_0 5 0 R>>/ProcSet[/PDF/Text]/Properties<</MC0 6 0 R>>>>/Thumb 12 0 R/TrimBox[0.0 0.0 558.0 261.0]/Type/Page>>\rendobj\r9 0 obj\r<</Filter/FlateDecode/Length 1241>>stream\r
+H\89ÌWÛn\eG\f}߯\98G\19è\8e\87\9c{ßjÇ\bPÀ(Ò\bè\83\e\18®\1dÇ-ì\ 6NÚ¦\9fßùh¥U\14KN\1e
+\ 1+\8bæpx;\87Üã\9fNÕñù©Q'/NÕ@J>\1fÞ\rÇ/_\eõîã`\94QÞ'Å\ 1â·Ãíð\b\91ü\10áؤ¿¨?\a£½a\85\83Yýür`õI9u®.\88ß\18\86G\18\17\8b¤\9cÍ\9a\8a\92×^]?\94\9b\1e\ 6\etÌ°\8coç¼Â?­µjÌ^3\ 5\ 5iòA\8ddc\91_\ f£×)fH¢Ó\ eÞ\8cD8IQtX§\84³äY\e\9bVFp\88\92ÑQ\f\ 5§\93\93@Øh\8aP\86]\12+Ñk\¢¬\85\1cá\ 4\rV1è\10`Þ:\9d\19\1e9í3\97 ®\87»áõð
+\9f\93e\89Æ\94D.éR\ 2\ eä´1¦*÷¿\83b\89%'§\96\ fÃâ\87£å\1f\92Ê\94¡³¼\19\16ßW\ 1!'U ª\80\8b\1d\11üS\ 5.¸&ÐýHl\82\8fU`c7úW\1305Áûv-w\8d\ fM\ 3éª\82·í\96Ô¯ýuÑ\1c\89]BM%Û*¸X|w\94áï\9bå\8f"64·í綻Æ}3Ýݹ\80
+\9bÅU3\95\9dÝ\15ÙÊT÷òH\ 4\1eÙé\1a'-TÚÊp\9cgØ~\83\fóá\19¦­\fwGx\96a$ø©îxº\90ód#Í-Ü®ño\13¸\9d6nZtÎmäýl¹\9b.
+\v\80#&J Ê\0\90':ðQû Y¾/Ъ\8a@ÕÚ©È:dxÂ\8e×\89\84\f0
+Á=~\8f\11_w ¯WÏ9hÊõkØ~\ 2Òd\93\ e\8c@\9cÓÁ5`ouÈoO'¨\10\8d\99'I\18\83'w\99Ëe#nOÆ+'ì\98ÁsN!>J0
+¢òÂz-\81Íêf\12\13hL¡\ 5t\12Ví¶k=ÀÓ\92\ 6_yoJå^¹\b¤c@TlPÉ\98©$ã¡&#ùÞ¶\ 5\1d\85{q\16½'ò³Þ\8aÏ Ã\8e\919X/ÐñD¸\12\8fÊ(¤ÙöÆ]ur?>¡°«\Ío¸n\82þû±Ûè>ýÝ\ 4\v\98ëaìÁ\ 6ÏBT¨EM¨Üªª±\14yLA\et        ±Ã¤C×0Ú\86bR\96}U`ò(D\9a:g\ e=çH4e\86£Ó0\f×0¤\1d¨\ f­\aV)@
+:ã²CZ\87\8dÔ\ 5\85\ 1\ap\ 4\anÀ¨'î\93\b¬f0~Ô\ 5l\10\9e¶|{\7fxÛ¸Þ%ú\88Ìâ¶O¯í       ÓOnQý¬\1d.\16w2¼.§  F0·jÆ\9b#ÊxT¹É[]×\9bj>]¿\8aûw\rÚ/pÿÖ°Þâ~{@§~\8eÚØYMÂ\9bXÜ°m¹©\9d\1cv.¸8\82ײWÁ¢þ`<\16·TÌø\9fS#\96¼(¼¸7M[0RÊ9+&Ò!Áâ\ 65õÑþþ\89`ª÷³@P\16\v\v\12    ¸k\8d­£\98F$\1e\11aqºßÛ[ö\19\v6\b\9e2ODºUáÛºîÄÂÔ\b¯âáEU\v®×ý\eÐh½
+G\92ÝÕ]»\91Ñ5î:1öîºl\1aqµù]màäy×­6\8e'\11#û( Ý\17R\9b÷_ÅþW8±Vö\15ò    \ 4\87|L(\ 1<¤î¡¬®è´\80Mjd\90#öü\84\95\ 6Ò\11dê2\7fy\ep@\16.\90\89=Y\1f\91ý`ët.¤\8e7-Ì\v\92ÃÛÕ!Ôî\f¼\ 1Àå5.\84ðÍ\80g¹Ì4þLr¢¬\1fÈ\r \8e(öÇ\9d\95%®¼§bÈùìâ&îzµo\ fwÖað\ 6\8b\r\0\fæ¥á'_\9d¶RHou
+Í×zj³LY
+\84\17иV&Ìn\96\15°n°cÒ²\eæRº\83*ÔG»óHd
+_\13õ¦ÓRzô\96¬Æë\eÃ\1e~¯ÕÙ$1\82\r\86\8,ø\1d-/K\8fX\84²pëÁ]\7fv~ªðõ\9f\0\ 3\0Òj\89\r\rendstream\rendobj\r12 0 obj\r<</BitsPerComponent 8/ColorSpace 13 0 R/Filter[/ASCII85Decode/FlateDecode]/Height 32/Length 408/Width 69>>stream\r
+8;X^=acXLq#Xrl5!h:6uI-P+\M-NSacjlKJm&EpL/R(-:5Mo"@rf<An]:cN7T$7`m
+]J31*UWWZ)Jtsp<=QD$J+9\ju?_\u\\6qHPpk^F#M:uB+=GP=FWq^l4FEWJY:fF5u
+EjNp/4gpSCN#qR=#6]s@WY@-j5(Da;.VXlu!6g8ZN2>I.==)2c"%X:Ua-9Wt7C;u[
+:bOoR%n$'j&P3-EB-'m6Q?j0^Ak"Gfd%mUtM,X&9FB!22>F!O5]<*CYKrfdBFp\@$
+GZ%N63\rfIN*Se]%P1]:F^\4GQ;OqUCXmM<Q?"(.B_6k@GGg+LmKmkN<NYuH37BB)
+\-"./dDf-XE:l.,m6L>'Wha.32p33moLj_\WI#0,K3QG[k2^I0q^H'>7amk"$WP12
+]<;58LL#1)~>\rendstream\rendobj\r13 0 obj\r[/Indexed/DeviceRGB 255 14 0 R]\rendobj\r14 0 obj\r<</Filter[/ASCII85Decode/FlateDecode]/Length 428>>stream\r
+8;X]O>EqN@%''O_@%e@?J;%+8(9e>X=MR6S?i^YgA3=].HDXF.R$lIL@"pJ+EP(%0
+b]6ajmNZn*!='OQZeQ^Y*,=]?C.B+\Ulg9dhD*"iC[;*=3`oP1[!S^)?1)IZ4dup`
+E1r!/,*0[*9.aFIR2&b-C#s<Xl5FH@[<=!#6V)uDBXnIr.F>oRZ7Dl%MLY\.?d>Mn
+6%Q2oYfNRF$$+ON<+]RUJmC0I<jlL.oXisZ;SYU[/7#<&37rclQKqeJe#,UF7Rgb1
+VNWFKf>nDZ4OTs0S!saG>GGKUlQ*Q?45:CI&4J'_2j<etJICj7e7nPMb=O6S7UOH<
+PO7r\I.Hu&e0d&E<.')fERr/l+*W,)q^D*ai5<uuLX.7g/>$XKrcYp0n+Xl_nU*O(
+l[$6Nn+Z_Nq0]s7hs]`XX1nZ8&94a\~>\rendstream\rendobj\r6 0 obj\r<</Intent 15 0 R/Name(Layer 1)/Type/OCG/Usage 16 0 R>>\rendobj\r15 0 obj\r[/View/Design]\rendobj\r16 0 obj\r<</CreatorInfo<</Creator(Adobe Illustrator 14.0)/Subtype/Artwork>>>>\rendobj\r5 0 obj\r<</BaseFont/AEWVGO+TeXGyreHeros/Encoding/WinAnsiEncoding/FirstChar 32/FontDescriptor 17 0 R/LastChar 120/Subtype/Type1/Type/Font/Widths[212 0 0 0 0 0 0 0 284 284 0 0 207 0 207 0 0 513 513 0 0 0 0 0 0 0 207 0 0 0 0 0 0 612 542 580 666 492 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 482 569 448 564 501 292 0 555 234 0 0 236 834 0 549 0 563 327 396 331 551 481 736 463]>>\rendobj\r17 0 obj\r<</Ascent 952/CapHeight 674/CharSet(/space/parenleft/parenright/comma/period/one/two/colon/A/B/C/D/E/underscore/a/b/c/d/e/f/h/i/l/m/o/q/r/s/t/u/v/w/x)/Descent -250/Flags 32/FontBBox[-157 -250 1126 952]/FontFamily(Myriad Pro)/FontFile3 18 0 R/FontName/AEWVGO+TeXGyreHeros/FontStretch/Normal/FontWeight 400/ItalicAngle 0/StemV 88/Type/FontDescriptor/XHeight 484>>\rendobj\r18 0 obj\r<</Filter/FlateDecode/Length 2674/Subtype/Type1C>>stream\r
+H\89|T   L\14i\16®¢»ªaÔV(\8bu»fªj=@\14Q\11\ 4\r\f\82\88\82\ 2\1e$\8c\ 2ÝÒÜØÝ\80\aJëDéæÒu\ 3\82àÈ\808\8a\820\\82 2^Èpj{\8e'\87ºÊxìh^áÏl¶\9aÄd\93M6ùóþÿ½ÿ\7fßûò½W\85cR\v\fÇñÉ˼6¬÷ö\9f\1d¤Úè½C£òQi\12´æ8'0¸0E*|9\9eFóQΧO\9fü\bx9Q\98dÝöå\17/m0\v1\eû7>î\9b\84Ä\1d\9a¨Hµ\8e\9f¿h\91³£Ùº\8cY7GÞyÞ¼ycÖ\85_¦L\b\81;´:U\9c\96_\19\1f\91 ILÐ\84éTJ'~Yl,?\ 6¡å5*­J\93l\ e\ 6h\12\bñ\9e\ fßÁ\a;\ 5\8a\11ñu¼øæ[\17W\17GWwg'~µX9LÉGiyU\94N­Òða"@d\94XC#æé4aJU\\98&\86O0ßü\97»õÿÐá£ây\11\8b\ f\8e\8f2{\81:1¨åÃâ\95sE\94\84±*\11   Iñ:M\94Jë4wE`Ð\8eD\15ïÎ+U[1Q\10\1cìpl\ 2\86MÄ0\e\1cc0lª\14óÄ°å\ 4\12ÇVãX\0\86­\93aSÍâ­\16\9dï±zì\16ö\1e§ñ\10üïø#\8bµ\16?X|\94|%q\92\14KÇKWK\9b\89IÄZ"\8f¸A<$\83È<\99Dæ-+\92õ[α\8c´¼i5Ý\90Ù"\f·à¢\9dÞ"É\94
+\86\91\80Q\ 3  9è*\8d\96Â?Ä\86\91\88G\97h0;£\87e£äwcgX\8aD\9f\14Zió        \99=9j\90£\ 44aä2þëm  l\18ñ¥ýÜ|\10\9d\816Z¢\r=hr\87;ÛCz½\r\ 2
+V(À·\15\eös
+̸-\19@\13è\8e'Ý09\v6ZÂFo ý\1e±ÞäMû6D!\1f\ 5ò       B´×LV>;\19/\ 4gÉ}dEÿÔÔ\0\92Ò§\ e{§è\97'òIþ\96r=Øà­0N\ 2\16zºªôä¹*m\99Z­I\8c\8c,M¬àä¹ÅÉBç£Ì\14\eÐ?¥ª@oût\84õ$©^4õë"\1f Ú\89lR\9e\9bi\12\8e\98p\10\ 6\16[\13\96]¼@ÀW0¥\7f\18Æ+^\ 6¼Fü2ßø­\9bÙ\9fV\13'N7\9f¾Æ\f\97¯Yéðµ\eZ\8c\9c¹\15>D°L¤a\rÛÁ\1a¿\ 4_H@\ 2¯èª\92\93\95Uº²È(Ͷ­j3\17ôQú?19àÅÉ î\81¾{"Ç\13B;uOð\05}\v©   ±\13;G\16\12ÓÄíÏ\85Ä\10Ù\ajâX\ fÝ\ 5\e\bêeAmn]îÏ\96Ùd®27âèæn´~\8aüçý=PР     ºn\9b»ý \eôyA}¸\9b\9fjL¿Î\80ÅÝãõ\8d\99\92óW\15o=/­:ÊæÈ(¡ïDÃ\95.Å¥¤\1au\19[\11\1e\85ñ_³\7f\9f\8aë_Kç\14\94äÔ0\ 3×b\96ø\ 6\87Ìã<H_é-\92úðê\81r\9e\83{ôüXmVÎ\ eN~O\7f[h4Å¥Ø\9c{Aõ
+eÏé\9dê`}0\83Ü\1c?Àbðúð\ e\9c/7¥í:ÃQU?Þ$¨Þ#ºàcî\fR¡ih*R#\rLEãaÝ£ÎÂÂrQ\f·ý}B}/~·_\18÷B"r?ÐpÑÐÁÀ_þ¨èø\95»q£r\b,\14\80«ï¯ù\85m\vp>\8d¬\99\15~û÷­çúýèC%\15\aÏ3à7d\87\16dpÈ×~\1aò\8f\8aÉÊIbåúL\13¤ß\82(\13~Gì°\870\85F\ 5\10\ 5§M£ø\9f\v\85I&t\1eÒ¡\80\94\e\90µøe\b\ 6\89§t\93`h\91É\93õ\9dÑÉ\90Ù\ e\13:m*\a ì)Õ,Ì\87\16úuä;4sMÀNM\ 4{<\80(©hÊodÞdå-W*öÊ\90\7fÖ´UÈJáÕ²â÷ÞÖ\8aê\93l\ e\1e^C< \ f\9c5ÖÖ)\166ÑTó÷\19{\r{ÙðÝá\11«\98ͪ²«ÿ\ 4¼èµ\91\93wéûTÉÂ\92^\88M±1õùAªÙ\ 4Ö4\95ºÅ\18b\8c\90Tó¡\aâÌúU]Nìc\0\ 3\8b\fìÜÞ¢  K\ 2£\82c9#\q!ûG\97Ó\ 5ÙGròØ®c\97ë®1¯ZÜg!I°§Óª\ruí»8CnF^\9eB\1e¤¿)`}xõ D°\7fLë5Ñi\9b\98Ùßô\82ôíõÇ ¹p6M_Ì\1dï&òµ¡ù\e\18ä<\ 3áÈ\ 1Í|5\13ì:/\16å\95pòvýMåg²Õ\83pª_\94Ç~$\84FuFYuRH¥'\83¬ì\1c\90k\16\87ì\9fÏ\ 4«\aWkÛÊÆä8èFÜ'\8dg\8dÍõ
\91Ìeô ½;#Í\90ÆR;»\82#\ 2\989!\ f\7fÿØöÛó®\v¡Aù\\8e>+U¯\90\eõ½àÑ\ 1S;ðê'\90÷T"\84C2\9d\9d\9b\95\7fL1\18\ e,Z\80þæ\8aHd\87ì\ 6g\82ý¶¢\82rvW\a±;F©÷c\9c=\9ba\9c\91Ëê Û\ fW?\1c\94º\ 4epr\14\1f\»añMüQ¿\ 4\96Ø
+®`Õ\8d¬Êdw~è¼SVt`\7f>{¤\878¼sÛá\18&|ó\9e\98h.B¹kµ·BçãÓ=ê*\93·\8aù\8b\ 2¸i\0ô\ 3\12\93í\0\9c'\v³ò\ få³ME\r5W\98ǧ|\97p¨|\0je°xZ\8dotì¾Ômlbj\92n·ÆÒ\b\97\17\90rô£\88²=å=à67\0w\18 ^\82«­°}Áèv\19õ®aÄ\8d\8eNÒÄÅ\15kÏT\16\97\9e.O*\8d\11\89\1f/N\1e       1W5\97\1c   \11\89\88²øÖ^qr\9eA\9cyQ\ fM¶Ï \81<\9a]xè\bÛPPÛÐÆtW\ 4-åPý3h\95\15æ\1c=\98ÏÖ\15VW]dú*\83æp¨ì\19TÉÀñÎ746-)\9eMIMIIM°4\92W\927Õø2\8b¿Û\12\9aÈ\19Ä!L\7f@,%³#²#6*ä\8dú.Áª\v¯\1e\82Æ!     \94\vûhôWÞ\11¹¢9ïg\83-X\82õ}ð\ 6û9ï\10Ç\19\7fÔN_\84p?\ f7Wÿß>>?ÿú_\9cü:òJ\ 6ÿ>\ 1ïÛûy\92\86\ 5{\14\v\8d$õ°%»>»\86u'©aÃrÂH6j7Uy23\90\95\aòEö/f\ 1qÿRuÓI.\9b\84\89Ò=\86\9dé{Xÿ\94\10õ:fVèãaÀ~¹÷¼«14¸À<F{Ò\14rô­(ÓÜÇf\99\ 6¨^s¿òþ\ 3D\ 2»ý\ 6\99\8c\9a\8d\97\1eÍ\97·¹É\e\97\94\8b\89\94\1fÞ\a\8c\83\84\8c\82\ePUbJu\1f\88\ 6\13°\87ë\ 5>\ 6\8e^\8cZR\1a\ e \80Íø
\ 1Àà÷\19à\ 3³¢\15w­¼}À\e÷\ 5ÎÇáÓ_µ8ª\1fL¤o\9d³\1a¯§©¿¸®z\7f\9e\1e Ë\ 5\9cq`\98Z\e$KK=Q´\ãk\1fËs¤ua\1abmlL_]\9d\9bp\1e\ eû@\80Ôcvø4Î\12èá\13pèøÒ\151@HÖû\9c\a\13°R\95`£p\1et ¬}´\e­¦\91\91\9c\1f\87Î\ 5\87~}\89s\eZz­Ç\1f÷\99÷\12Îû\12÷\b\a\ e»\80Ôbvøxw\12Ñã÷|ã\13¸ørøx\153û¼\ 6z\88{\86\7f\1ec{bbP\e<nÊç\1f÷\9f3û¯\aû=æ`×῾²¡\1e\8d\ 6\13x\90<\ 5Ù\ 6\88±\8a·¾\1a\ eu\8bãHvøxw\12\98ø^\13p\98øx\15÷Lüx\ 5ß\ 6÷Røx\ 5/\ 6-û£\ 5\13°{^}c\80c\b\88\ 6\81³~³{¸,÷£\18\ e÷}\8bß÷Æé\8bw\12\9dùS\13°\9døx\15÷&üx\ 5Û\ 6Ù÷z\ 5\13Ð\9c¿\9a½\97Å\b\8d\ 6\97R\99[\9cUÕû{\18Û\ 6÷0øx\ 54\ 6\87{R~X\83Z\19\88\ 6\80¼}¾yÅ@÷\86\18A\ 6\8b{W{W\80Z\19\88\ 6\82½~½~ÁJ÷\8a\18\ ec vøxw\ 1\93øO\ 3\9bøx\15÷8û\81û@û\8b\ 5ì\ 6Ñ÷\ 1\9e¨\9b¥\9b¨\19\8d\ 6\9cn\9bp\9eoÓû\ 1\18î\ 6û=÷\8e÷9÷~\ 5+\ 6H$zq{r{o\19\89\ 6{¦|£x¦Fó\18\ e\80\96ù6\97û^\96÷/\96¼\96üt\92\ 6øJ\91ûL\91üo\96¸\91¨\91\a\1e `E\82\99ÿ\f        Î
\vã\8f\f\r÷c\14ø\8b\15\ 2\f\0®Ý=_\rendstream\rendobj\r11 0 obj\r<</AIS false/BM/Normal/CA 1.0/OP false/OPM 1/SA true/SMask/None/Type/ExtGState/ca 1.0/op false>>\rendobj\r10 0 obj\r<</LastModified(D:20121108194719-08'00')/Private 19 0 R>>\rendobj\r19 0 obj\r<</AIMetaData 20 0 R/AIPDFPrivateData1 21 0 R/AIPDFPrivateData2 22 0 R/AIPDFPrivateData3 23 0 R/AIPDFPrivateData4 24 0 R/ContainerVersion 11/CreatorVersion 14/NumBlock 4/RoundtripVersion 14>>\rendobj\r20 0 obj\r<</Length 927>>stream\r
+%!PS-Adobe-3.0 \r%%Creator: Adobe Illustrator(R) 14.0\r%%AI8_CreatorVersion: 14.0.0\r%%For: (Brian Demsky) ()\r%%Title: (release_seq_edit3.pdf)\r%%CreationDate: 11/8/12 7:47 PM\r%%Canvassize: 16383\r%%BoundingBox: 6 14 564 275\r%%HiResBoundingBox: 6 14 564 275\r%%DocumentProcessColors: Cyan Magenta Yellow Black\r%AI5_FileFormat 10.0\r%AI12_BuildNumber: 367\r%AI3_ColorUsage: Color\r%AI7_ImageSettings: 0\r%%RGBProcessColor: 0 0 0 ([Registration])\r%AI3_Cropmarks: 6 14 564 275\r%AI3_TemplateBox: 487 171 487 171\r%AI3_TileBox: -3 -211.5 573 522.5\r%AI3_DocumentPreview: None\r%AI5_ArtSize: 14400 14400\r%AI5_RulerUnits: 2\r%AI9_ColorModel: 1\r%AI5_ArtFlags: 0 0 0 1 0 0 1 0 0\r%AI5_TargetResolution: 800\r%AI5_NumLayers: 1\r%AI9_OpenToView: -74 406.5 2 1835 980 18 0 0 43 129 0 0 0 1 1 0 1 1 0\r%AI5_OpenViewLayers: 7\r%%PageOrigin:181 -225\r%AI7_GridSettings: 72 8 72 8 1 0 0.8 0.8 0.8 0.9 0.9 0.9\r%AI9_Flatten: 1\r%AI12_CMSettings: 00.MS\r%%EndComments\r\rendstream\rendobj\r21 0 obj\r<</Length 5210>>stream\r
+%%BoundingBox: 6 14 564 275\r%%HiResBoundingBox: 6 14 564 275\r%AI7_Thumbnail: 128 60 8\r%%BeginData: 5086 Hex Bytes\r%0000330000660000990000CC0033000033330033660033990033CC0033FF\r%0066000066330066660066990066CC0066FF009900009933009966009999\r%0099CC0099FF00CC0000CC3300CC6600CC9900CCCC00CCFF00FF3300FF66\r%00FF9900FFCC3300003300333300663300993300CC3300FF333300333333\r%3333663333993333CC3333FF3366003366333366663366993366CC3366FF\r%3399003399333399663399993399CC3399FF33CC0033CC3333CC6633CC99\r%33CCCC33CCFF33FF0033FF3333FF6633FF9933FFCC33FFFF660000660033\r%6600666600996600CC6600FF6633006633336633666633996633CC6633FF\r%6666006666336666666666996666CC6666FF669900669933669966669999\r%6699CC6699FF66CC0066CC3366CC6666CC9966CCCC66CCFF66FF0066FF33\r%66FF6666FF9966FFCC66FFFF9900009900339900669900999900CC9900FF\r%9933009933339933669933999933CC9933FF996600996633996666996699\r%9966CC9966FF9999009999339999669999999999CC9999FF99CC0099CC33\r%99CC6699CC9999CCCC99CCFF99FF0099FF3399FF6699FF9999FFCC99FFFF\r%CC0000CC0033CC0066CC0099CC00CCCC00FFCC3300CC3333CC3366CC3399\r%CC33CCCC33FFCC6600CC6633CC6666CC6699CC66CCCC66FFCC9900CC9933\r%CC9966CC9999CC99CCCC99FFCCCC00CCCC33CCCC66CCCC99CCCCCCCCCCFF\r%CCFF00CCFF33CCFF66CCFF99CCFFCCCCFFFFFF0033FF0066FF0099FF00CC\r%FF3300FF3333FF3366FF3399FF33CCFF33FFFF6600FF6633FF6666FF6699\r%FF66CCFF66FFFF9900FF9933FF9966FF9999FF99CCFF99FFFFCC00FFCC33\r%FFCC66FFCC99FFCCCCFFCCFFFFFF33FFFF66FFFF99FFFFCC110000001100\r%000011111111220000002200000022222222440000004400000044444444\r%550000005500000055555555770000007700000077777777880000008800\r%000088888888AA000000AA000000AAAAAAAABB000000BB000000BBBBBBBB\r%DD000000DD000000DDDDDDDDEE000000EE000000EEEEEEEE0000000000FF\r%00FF0000FFFFFF0000FF00FFFFFF00FFFFFF\r%524C45FDA0FFA8A8FD7EFF27277DFD5EFFA827FFA8A87D7D52FD057D27A8\r%FF7D7D527DA87DA87D7D7DFD05FF272752FD08FFA8F87DA8A87D7D52FD05\r%7D527DFF7D7D52FD067D27FD3CFF7D277D7D277D27272752F8F8527DA8FF\r%2727F85227275227F87DA9A9A9FFA9A97EFD04A9FF554F7FFFA827527D27\r%7DF8272752F8F8527D7DFF2727277DF827F8275227A8FD3BFFA87D7DA8A8\r%FD087DA87DA8A8FD047D52A87D7D76FFFD0BA955F97FFFFF7DA8A8A8FD06\r%7D587D7D77A8A8FD087D277DA8FFFFA87DA8A8FFA8FD4BFFAEAEFD0FFF83\r%FD0BFFA1AEAEFD15FF7DA8A8FD48FF7E8383FD0DFF5E1083FD0AFFCA9AAE\r%83AE83AEA8A2A2FD0FFFA8FFFFFF7DA8A8FD43FFA9CBFF83AEAEFD07FFAE\r%AE83AE82FD0DFFC3FFFFFFAEAE83FD15FFA8A8FD43FFA3A9FFFFAEAE83AE\r%83AE83FD04AEFD11FFC3CAA8FFFFFF83ADA8FFFFFFA87D7DA87DFD0EFFA8\r%A8FD40FFA3FD05FFAEFFFFFF527DA8A8A8FD11FF76C3FD05FFAE83FFFF7D\r%27272752A8FD0DFFA8A8A8FD3EFFA9A9FD08FFA8272752277DFD10FFA8AF\r%CAC3A8FD05FF83AEA8A87D7D7DFD13FFA8FD3CFF7FFD09FF7DA8A87DA8FD\r%13FFCAC3CAFD05FF83FD18FFA8A8FD3BFFA9A9FD1EFFA8277DFFC3C3FD05\r%FF83FD17FFA8A8A8FD3AFFA9A9FD1BFFA8A8FF5227A8FFFFCAC3FD05FF83\r%FD54FF7EFD1BFF7DFFFFA87DFD04FFCAC3FD04FFAE83FD19FFA8A8FD38FF\r%A9A9FD25FFC3FD04FFAE83AEFD18FF7DA8FD38FF7FFD26FFA1CABCFF5E10\r%33FD19FF7DA8FD37FF7FA9FD26FFB5FCC3FF335EFD1AFF7DA8FD37FF7EFD\r%18FFA8A8FFA8FD09FFCAC38CB5FFAF83FFFFFFA8FD17FFA8FD37FFA9A9FD\r%17FFA8FFFF7D7DFF7DA852A852A87D52A8FF9BA15277527D52FFFFFD047D\r%A87DA87D7D27FD44FFA97FFD17FFA8A8A852A8A8272752F82727522752FF\r%59F852F827527D7DFF2727F827F827F8F827F8A8FD0DFFA8A8FD35FFA9A9\r%FD19FFA87DFFA8A87DA87DA87DA87D7D52FD057DA87DA8A87D7D52FD057D\r%52FD0FFF7DFD36FF7EFD25FFA8FFFFFFCACA84AE83AEAEFD19FFA8FD36FF\r%7FFD29FFC3CAAFFFA8AEA7AEA8FD4DFFA97FFD15FF7DA8FD12FFCAC3CBFF\r%FFFFAEAE83AEAEFD15FFA8FD35FF7FA9FD15FF7DFD13FFCAC3CAFD05FFAE\r%AE83FD04FFA8527DA87DFD0BFFA8A8FD34FFA97FFD16FFA8FD13FFCAC3C3\r%FD07FF83AEFFFF5227275227A8FD0AFFA8A8FD35FFA9A3FD2BFFCAC3FD07\r%FF83AEFFA87DA87D7DFD43FF7FA9FD14FFA8FD16FFCAC3FD07FF83AEFD49\r%FF7FA9FD14FF7DFD13FFA85284FFC3CBFD06FF83AEFD12FF7DFD36FF7FA9\r%FD13FFA8A8FD12FF52F8CAFFFFA1CAFD06FF83AEFD11FF84A8FD36FF7FFD\r%27FFA8A8FD04FFCACAFD06FF83FD11FFA8FD38FF55FD2DFFCAC3CAFD04FF\r%AEA7FD4AFF55FD13FFA8A8FD19FFC3CAFD04FFAEFD4BFF78FD13FF7DA8FD\r%19FFC3A1FFCAFF5E5E83FD0FFFA8A8FD39FF7FA9FD12FFA8FD1AFFCABDB6\r%FF5E1083FD10FF7DFD3AFF7FA9FD2CFFCAFC8CC3AF5D83FD10FFA8A8FD3A\r%FF7FA9FD12FFA8FD0DFF7D7DFFFFFFA87DFFA8FF7DA8C3BC93FF7DA8A8A8\r%7DFFFFFFA8A8FD05FFA8A8FD3EFFA37FA9FD10FFA87DFD0CFF52527D7D52\r%522727275252F8FFA84BFD04275252FF7D2727275227522752F852FD3FFF\r%A97FA9FD10FFA8A8FD0BFF52527DA8527D5227527D52527DA80552275227\r%A852FF7D52275227522727522752FFA8FD3EFFA97F7FFD1DFFA8FFFFFFA8\r%FFFFFFA8FFA87D7DFFA8FFA8A1A1FF7DFFFFFFA8FD05FFA8A8FFA8A8FD3F\r%FFA97FFD11FF7DA8FD1AFFCACACAFD0DFF7DFD42FF7FA3A9FD0FFF7DA8FD\r%1BFFC3C3FD0BFFA8FD3DFFA87DA87DFFFFFFA9A3A9FD2CFFCAC3FD48FF27\r%27F852FD04FFA9A97FFD11FF7DA8A8FD19FFC3CAFD08FFA8FD3DFF7D7D7D\r%A8FD07FF7FA9A9FD0FFFA8FD1BFFA1CAFD06FF7DFD4AFFA97F7EFD11FFA8\r%A8A8FD14FFA8277DCAC3CAFFFFFF7DFD4EFF7FA9A9FD0FFFA8A8A8FD13FF\r%5227A8FFFFCAC4FD52FFA97F7FA9FD12FF7DA8A8FD0EFFA87DFD04FFA19A\r%FD54FF7FA3A9FD11FFA8A8FFFFA8FD0FFFA8A8A8FFC3CAFD53FFA9A97F7F\r%7EFD12FFA87DA8A8FFA8A8A8FFFFFFA8A87DFFFFFFA8FFFFFFA1C3FFFFCA\r%FD53FFCB7FA9A3FD15FFA8A8A8FFFFFFA8FD09FFCACAB6C3FD55FFA9A97F\r%A97FA9A9FD21FFBCFC8CFD5AFFA9A97FA9A3A9A9FD15FFA8FD07FFC3B5C3\r%FD5CFFA9FFA3A97EA97FA97EA9A9FFA9FFA9FFA9FFFFFFA9A9A9FF5252FF\r%A87D7D527D7DAF27767DA87D7D52A852527D7DA8FD58FFA9FFA9A97FA9A9\r%A97FA9A9A9A3A9252BA97D27A87D52FD042752275252F87DFD0427F82727\r%A8FD61FFA9FFFFFFA9A9A9FF7D7DA8FFFD047D52A8527D527D7D7D277D7D\r%A87D52A8FD79FFA8FD86FFFF\r%%EndData\r\rendstream\rendobj\r22 0 obj\r<</Filter[/FlateDecode]/Length 16215>>stream\r
+H\89ÜWýrÛ8\ e¿\17Ð;ðæ&7ÉÌÆ´üíô/ç«ëÝ&öÄN¯{\99\8e\87\96`\9b\eJT)*©ûô\a\92\92¬$MânÛIö\9a©E\ 2?\80\0\b\80äÎ?Ç\93ýA(ç°ß¬Õ\89·³s¤\80\ e\88¥\92¡\10\95!í^ì\11¿U«#h0ìÍrà{P)\97ñ\81eYæ©\91Þ=T\9cÅä\18¢ôz½Gv÷\901åZ\0²\14\b`)ÌRø4\83\90ëf- \17{ÅÚ¨ì\98iÄù>íQ¿Aº\a­.\19\9f\19>\8boX\9aò/\86Ûiö\9aH;\94Y\1còxy(?\1f\90\ eZAÚ\9d\16itÛÈû\95_@ú\14àX\ 6Y\ 4±\1e+\19@\9a\1eI!Uz@\8eÖhú\19["\87\91?@\byK\ e\ 5\v®+"§2Ö\b\9dÂ\87·k\ 5¿\82\92i\85{\ e\10BøUÌ`Ø\9e\9dr\ 1\18¦\88iâÛ \r\86~cv\98q\11\9e\1c0\80ÍN×\90\9b3kÔe\8aÖ aflÈÝÙ0BÊ\ 4´F×p\r\13ø\8b·\87UG\90hÿv¯.`Éí&bl?îåj\95L"¦®ÓûA1Ì)D\89ÀM°1kõºÄïúÅ7G \a\96»ß$û\r߯µI»Û$íF£\96ëØÄ\16n8Ü\1e\90s\19\83s\7f ôÄmb«U¯»_ǹÈ\ 4¨Ë\98\9b°5\f©ïü?\93!\bÄ\97ò§\82Y·í\9f¿ùu\80)SKиùRdÚfg¯X\ 1ãû\8e­Ál³ï\16\18%\10Oå{kã~·EZõ\ ezÓ ~¯Ù&ý\1e*îYý­&ñ\eýrI¿øuz\8d\16££P\8e»·3Æ-\1a)¾äñ\81ßó1N\8d¶Û¼·\8a\87\9b½ë6HÏýX\17j½Êÿ~ñßÙ\8ank\rqn;æÌÑY%\aêµ³    .{\12\87G22±7)y\88\9b\1fc^\b¹t¼rl9(\9e\95×ìÓO\99Ô\90¢.\ 1¤ß¡KÅn\0]îÑAÈA!'¥\ 3\85lz\14
+Áè     \v2\rô\câ\ 2\1d\150\8f^\96\12ÌA\98ÕFYÀ\15¦ÅBÀgÊ6\18'Ϭò P\ eVÒ£àD¡"
+¥(wê¹Ãð
+\86\97\98ت÷¨tXé°²\82\95%V:S2\aÍ\1c4Û@=\9a\95Ø\90-\97 h\88\ 6\ 2Ð\0ãMS\rJ\18/R\bLâÑy&\ 4h\9a0e"\90¬(JD,\ eç\ 2£¤l]¢¶\90\ 62Yc¦¬4Å:\rÁT&u6\94ËÕb©CXÐÁ    \1d¥\82¥+¯$%ؤ#\1eg\ePñ]CL£ì>Ù{\80+¾R\85\v@U<\ 63\8eX\1adÂL
+\0Cz¾ú§\fRãd(oc
+\9f\ 3Á";Äìâ\ 1\13(PJ-°\86yüÐ\8c%¶<\ 1\91Ä\83a¡73\17       l¼<1\9e§  \v\80\ eÜf\fòdË?'T\9a\1c\89C4\89Bd?6\911ÄVi1q:ílCwÄ\90ßp\93 eÐÊ\98ÿQ\8e\16\8a¹\1d\94´\96ÚJ)í¶3«Î£\v\8e\ eçé\81\ 4×\91¡I\10»×\9b:\9bã1X\1ah'\bÕ+\99¥\98"\1e\1dTRô¤2\1e¸Ì8)\8d;q¡\19:ú°\9a®Ã\124t \91\ 3\8d
+¿G\ e\10\97U5\97\8e\15\9a\9dÂ\13\98V¤ÝFD,P&ß±Û[\18\vlA¸\92v\15íÑU\16/\99Ê"Á2\8du\88\aÂ5\r\18ÊyÓ\13ÛFۿͦ)\1e\e\9bÓ¢9³mê$\ e¤9Å\ fȬz\9cÞ=[¯è\1d\83t]{ú_§\14û`¡\92LU\ 6Óu\ 2Þ\95ßñórÆ\93®I1,ð)c\ 2'\1dÊã\ 5\96\85^W\8aÍ\84Â\ 2°WâÍ\ 5ãl&\1eözSsXó\9a3\11òÅ\82¢O\91=~i¢d\98\ 5Ø\118jÔ¦·¡ú^\9f\8e"X2âùý6Å\ 6\87øý.e       
+|έè÷è1\b¼\934üV\9e´Xl_ ^\ 2i´ê\ 6,0\8dg\93u4\97bFÝ7?±\9cçm\17Î\19\86w\8c{cN\ eï<ñì\8dn,2d½U2K\86ñBz»î
+8ÅÌ7a\1aÍÿĦ\86\9c°\19M2®¡Æx²÷¤"<¼\14\10ÇDa;-¾ÏK\1fÃ\ 2oL\eqG=\89o@Ȥ¢¶¤`       \91ÿ0\95<¯z,XÌ\14±ôRó;\8e§ß\98a\8c6º7´-\942½Â[#v¦´Ôé¦wõ9Úóú&\81\159TYº"S)E©ö.«Ô\9e\93-Õà_Ç\1ac+\10\8fb\17 \87\80û+á¥ïÕ­\82èÇW@ækÖ~Äðxµw\12\1e|m\81¯ðË\95\1cï[\12Ëv"\9eF\9b|ªPƦS\ 6\ 2&k¼\rEOi3ÑÀ6\1cb"Ú¦³±VF\89\91É\8a%`uêÕ©ENJ\85mÓö«­o\7fÿé\9eøÍ\ 2}Ç1\ f\1c½ÆãÁ£¿Çx%²\13r\80Ñ\88\8f\9e³\bÈ/\1e\9dp|gAÁ­\93\91W¯uÛõ\ 6¾\ 3j\9dn¿ÓkÚA½Ñh\987@ÝÇG\9aëæ\1f\98W¼{p²ÆÉo8ø\13I·¤EÎÈÕÇ:     \91úáÂâ>àmÂõ²7\1eÁCd\81ß{¦]!\95eB\7f|ƾ:þk\1a\ 3\1f\1d¸?káÅö\ e\r¶vÈ\7fÄ!\e\7fÜ°Mô\9fÝÂ1ÃÛ9>2Ì¢ãùÖÆî^]Ø«»²g:FÌÆø\8bw\9fî\8d\ 3o|X\9aQ¬ö-)ô\ eÕU7ç\81\97\16ðWrÕ¯;\96«D£æ\1f9\19\15Ý#>¢<·õXâ]\10o{ÇL3ogF\8b\8c\99q{qfjýÕy\8bÐ!Bw\ 3\1e&ÝÎÌ'ô\10»
+ÙM\13©\1d©ÛÈQaÂk\8eT/P\f»È=\12>[®\1d©Ù!ô\ 2ðò´\9b°0t´7Ø4\86d\90iI.\98y\7fñ/pO\ 1ºF\12l$\8a¤<Ê\84ÝÎ\12âôá¹\rá;¼þ¿g"\83Òrk¥\11Ç\9e6\97L\85\ 4\1d\93ª\14¶ü#%\93\ 1^\19\a\18\89\9b\\96\ e\94b.$»uRüù¶¨êuÒ)\ 6\8d\18¶;­b¸gÄüb\8a%<Ñæê]ø[.hÖÈmí41Á\v{\8b-;bñ\rK'eDè\87³wç2\84¯n\1d\1cá;/\84}<M\15\9fã³!}àÍÏVñ\ 3ôWPÁ
+\9f3
+òÝ.Ò®à\9a\1f½Nòàìþ;Ng7L¥o6\ 1¿\ 3½Ù¤\86¥§\8fàbì·enæÀ_þöÑÁ³\ e\b\8c\90Á5\84ÛD¦@þ Äü«~ÍñZ\81\86ú[ø\86É1\ 1}n\9dxÞ¿*ú\amÿwFÂ\7f2\12[ùÏÙ\À6\89ÿì®þ\9d
+ýàfëR7Ð\17Îhã^\90¥ZF/ÛÉ~^\1e\1e¤Ì\eÍ\r\ 5KlÛtüéu\81¶¼"Sþ\1fª4]ܾâÓø\85Ë \15<ø»÷âòBÿèÖnµ­/ÝsýÖs~¬·ñcýÒ~´Û½ç\1c¹å¡^mãL\ e|Y\87\1a\1dÿ9\87\97«m\1aw\89|á\+\9eµ\8f94\97\1aÏ~ó\98\1d)¾äñ6®=\94y\ 5ç¼mp\13\99©\0\ ee\16\87/~ÐãqôÒ&D Y\88÷\9eïµ£ÿ\9dvü+\94A\16A¼UáTÀVøê\fB\9e\ 2R)2S9\1fQÍeÌ\ 3\94\r\86¾O\8esA\82\17\9a,!§\ 2ó\10bPd¬ \ 5M6Ï«N»ÝlçN\r\86\94\9eK¦B\12H!\15ñɼ4¾^T\90]¢°\8d\Çø"\95\99&K%³äI(G»ÿGz\95¶µ­3Ñ_Ðÿ >lé\ 5²\11H       ´ÍbÂ\r7\14J(ô^è"ÛJbâX®d\87Ò_ÿ\8eìx\v¶lú~á\ 1|4\1aÍræ\fv\bØ$Þö¸Ìí~5 \eáÁ9áSt\85¹C\98ñ\e\8b\1e¼äÛz£þ6Ûé:¸BHQ,#º\8fÜ«&ü¸p\1d\e^%÷¤\1e³ì0lq\eC­hOà\81¡#nü&\ 5½\88Â\9c\9b\91Øãr±áãj\89\8cxeÀ\16\ 4]\93_\ e\r\a«\86i8Oaú\96&\9f×Ò\10[\13\17O\bº¤v\90î¸ñ*\1a\87Õf\a×Ð\ 5a6Ô§Ãå\a4Ó°Áw±¥ü\ 2ß'\10ç\9c\13Px¦a\11Ä\1dFg\ 1ËVsÀ\ e¼ÚG6£è%\90ÌËúî\82h\ eÄQÅ&¶´ \87k\8drµ\\8d5ð¬3軦\19\ 4ê\860\ e\8eÃ×Ð\e¿ªº&!z×\e\1978ÞV±Ï×ÔÎüv%æhìë\91øªQ¦\13Ý\1f.ñy\8a*\1f©\93ø\\8bgõär\84.V²\12\vÛ\b/ȹk:\ 6d¢³,ª\94LÔQg \1aÅ\8bê(+\ 5       Ôu\18û\1cw\83"¬D3´ò@Õ2\94¶ \91ä\X\ 5yϦ¹ÊËÏpPÉж\93\1cs|fØ*ÔÀì\8dÔ5F ¢\9c\887°bþádlKÏù|õdp"æõQØÕ`\14\9dQu`\8d)\12Ñ-\14èÒÝÀ4]h ,j]!c\f\89O\99,qOD\12\88g4\1a%io\15~]*ýï\ 1áÄn\12¬\ 3v{Øö¹Ç\bJ§^ß\97X:\ 5ý¤ÐG\8b\12\839$°£\ 2¿äûÐ\13\9cØ\ 3r\ 1_D\83~rqDyÞ\10\92\1f\8dn]\9d\ 2\a/¸õ\1fÃÒó}\15¯ÌrÕ\9bS\99'Ï)Ìã)£s\92í¯ü±É\b?;û»£÷Êóº\12âÕÄÆ\86sòtÁA}\90~Ú¿ûb<\ 6\aÇ\81ë\1e)\9b\ 1\vÿɱ«hÑ)&ÖÒ¬.Å\1a|÷ÅZn\83Õý\ 6£c\ 3ÂfiÐ`pÙ%\85-`Y0\riºEÒ²ãþ²\0øÃíON\8a\1dª\10\a\ 6\ fö³\ e¯\82\89»||±He\1c\8c\aìE.ô¨%\98\8cZ\ 3\90ï\8e16dÜ\1f\1c\82µðµBüòfF\97\14\94'EX¸£1ªbg\88\9fàzé±\82âl?³9\v¨ù\ 2W§ª¼F!&J¥ÞÒõ\14"\ 1r\19´à\94 Ý\9fy\bJR\8c$\8e\1e§ÄB\1c/Dê±\85âóQÔ\vÂ\ü»£S\15t°Ò\ f7\9c2úÌ=\93ð3iì\89ºÈ\864!\b\0ñ'\9fwµon\82\r\v\19\89\8bv\10\\16\1eµ@þ!\87
+\13\1aA\86\18\99øI,^ض¡|üàrW\9b
\ 6\96B¸1±"3þm\16\ 5ïè8ºÞàȵ`\8d{´ÊÅ
+\1fLkÌ°c)\94\8e¤\91«\8a\96s%\9cÌÖP¹r]ÖRà\14\8bÂ\1fôò\15Ô3Dþ©\98\9c9\15þ\81\b½\9eºsÕÂ\86É¥\8fòn\80Êð\ 4Ú5\88\1dkòÿ\10\8dô®h\98v1\8bÜʦâhµ\90¾»áÅ\98j\1e<ÿµ×\fª\92\14P:\9e½¡!\93Ö+\93\11L[Ü\86Þµ\82\1c窾49²'=4·¡\92<]º¼£¾\9f«ò ³ddü.0\83F\ e¶t\10ñEÓ\13ê\11ix\80eo\89zc\90Ç\17UW¬q¢êÏ÷)\9aزÀ¬\bÙ(ü²\97\3c~\8eÙL>\9bRÄjÂ|\8eÿq­"O®¸#\99ÛjYhÙì\v\82\aÜ\92ܾòå\10è\0o%,RÏ~0A7å\aÒ#\1cÂ\84+×O6É?\04\18\v¼Ô4èD±g\86+(üÓ\17¬½p7L¾FÔ\eê\fPøØè\96.¥ær\89\1c     Eï\11ÿu\9cø\ 3Ì!²(¢\81\r1\b\85&¡Üp\88Tz\a-\10¸Ñ\ fç\8cï6JP\7fè\91\87í      éÓ[J\9f«¸ô        ÕZ\0õµNåÆ\97\844\8bdR\80\86ÒÒ\r\10\ e 'ô¥VZQG±Å'84\14±\81ü{\87D\8c\9e\1dÊ\ f\81\1fè\821ðÁÙAx\8e\r28\8a\v¶x¬|Xá`ùð\97FË?\95\1f®\8abxõ\8aÙ\13j¡ÊGê\\11\8d2\1d4WV\eØ6+k Õ\ 2\ 6IkY\81YJË%QBþRXCà\1e\rÝ\99.Ãt\98\89\9aÆø¤¤\10\90sà¢ú\84\14f,ÄÚ!£{qÞ\92ó»¶âI6(îHZx<\90#\ 6u¡Qô@Õ¤oÏ\r\9a¬<\87Ó2Ç\98^¦lR\96:¿Ä,bº5\1dÅ5l\92ÀV.n!ñÜ\ 3Ù¦L¬ø\18Íâ²\90\ 2Æ\89iÇÔª\9cÌgeî<\99\92Hz\18U®â<\f,\89v¶ËcØvt3\91\92T\f\añïd+.\9b\97M² ¦¤\8bxY5DkJÜåe\8bL@Á,dïæe\rV\10jÉ1fMóÄß3>YÁñ)Ö #\11\ 3¦¢Ä2cÁ´^!À8ê\97]V\13Ä\97\8eÑ\80\1d\a\0µ5Éjå\ 1¸äé\1e@w¥óCÒÁp\ÞÀLg\10\ e×Ò
+\11\82\87Æ\96E\97y\88f×3T\1e\v\18q\94>\97Ge\ 4*\19\ 6\19ìo:º/\8dn/.ïß E]î\11\98±\19\1d\eAkÕÓ¯\12z+Ôq¥;ŧÿ\9cài¡b\92¯\9fÜ1\83\81bûÊ®P0ű%>ÊQ\913¶."gZ\85\9d²õÂÆý´\85'jo³f\9e1\a¥     $\11l\eyH'`­ýÃ\86\1cÉ¢\19ÖÜÏ\9c¹>V\8dm\v\92ÙIÇc\90Q¹Ós\ 5ö,¦b\1eê\84\e\13\7f-Ë®8\ 1ôR«R×Ò%²=\ 4ÆJX\8aÃ\5\9c9\96p\8e\80ú\18¶¢§²\ 68ð/È\14\87ÛÔ\91¸*\90¡¾WM¬ÍäC\912¡       qÎõ\0\1c\ 3\85N)û½,\8f\f\94·JÄme¨\bðÐÄv¾ÚXâ$
\9b¶ÄÂ0\94\8bõ\8f?\9e½\ 6\8a²Yä\f¤Ì1\1c3g\8bõ ÐÒBÁ'Õ`ºë64\88\11®\82\990\ 6+\ 3\aM(O\94ÿ6jR¦bÆ%Á\8dt\ftS\8c\1f
+\80C\8a(\80e ¡\9b\87\8eÓÄA&|\8eÙ\8c'½.\0\ e½.\80\8dy]\0\1d÷:U\82%Þèr¢P­+þ\94t±¯\ fm6\ 6Í%\81yªl.\18\84ËË\ 2\14\17q\92\13giB\86­\12\92·L¦!'E¨K¨/\9f¹\1cØ\1eå*mÉpÞÚ\9b#\86\12\1d\9f* }Í\ 4ovHôê\f\8d#BHØ\82hó'\19_F@êL\ 3ýp\84J\9d\86.\ 5ã¢N\0G\8a¡­\f)\ f\ 6Ùwç@¹hD\1c×FClM\ \0tImwecè\f\ eWá6¶\ 2¹_êèT\85sJ\1f®\ 6¯\1cAPÔ\16Ù\80Ç\86\92\ f.­£3ª¢\vÿ\13\8aTR¥ë­\ 6¨\85*\9dQo0x»¯\10Á\80âcãÃÅæÝöñí»­#üeçloób·Ûf§óikb½>ë¿Þ)mõ\f\æë\a\9fÿ>9Xkµ?\9f¾?o|h\rï·ÎÛÌÕ\9aý\93úùÛ\8dZ£±V­råA\99ìT×ÛGßÊ\7fµ\8fwlÞæÿÔ+¯6ÚGÃ×,\0\9d9ÝÉß\9f\86íã\ 6\19õ\8cwï5¥\Þ\9a<»j¨ÿ\v÷5\95þF«ùß©£<|í6þÛÝéÌé\90w\ 6#gºýþ`Íí+\8dõÛî\83¹uûjC\19WÏÔTcëÍÃqóæÓÝ}çºW¾É¾4\8ek}m\1fÏú_Û-^\9eo+;\en¿tª\8f_mxÁêÿø~á*㯷ͮÙ6¿´ÆÝ©Ó\9b6ÿ«%ÂñcSÑjÃ\9fíã\ f[·¾\1dp\99÷¾M¾Qømó§2Ð\a¯»»o\1fÖ;£Ý5Ë÷á\vÖÝW\e\87\ f¥míDÛÿTêM\eß\8f\8e;\e{\9bÛÝ\8f;?¶Û½­Ïý\1eqÿz\7fs¶6=Ò4<\13¿\19Û'ãáÔ¿¹V­à&3Ö\7f´\8cogz×Üø°µË¶ïÝÎp´ùSøÿ¦}t6Ý{µqptóµÝ±´­ùö»ó£Js~ÿÎh6+|¼×aÚ ¶=kÕB\8b\9arÆo lÍ-Ҽݫê-£WÁ\90ßÚù»Òî\ eé\9aÍ˹ÿ\82\7f\87\eíÞàxíödçp\9fC^\ 6w\a\9b=úmûøF¿kÕÕµ¯\9eÙÿq_]ë©#Iø   ü\10\98\8c\b\12\ 6\81@\ 6e0"ç`\ 3&Hädxÿ-u\v$°=sfg¯ö\86¯QWWø+gvn0(C\a\9c\86K\ 6t\87®í\f\9c2ÂÚO\87ÌÐlÏ\8a$õá,I\91OÖ£8\88þÉ\90B\e\17\ 5\91<¹ÉÉó[\f\9d\89\8cÂ\9a'¶#«\98\\fÊcÌ,Ú\8b¾AèvI"\93\91\83Q)«¿\9a|:¯lz¶*\ f\91'o
+\ 3¿\8a\10\0\91P¸)ða)@ù^ë\ 6Ñ<\86¾Å\1d\824BPKó¯l\8cîÓ«)ß\94V\84¤EÔ£üùéu     ô¤Ucªîn\8b¯\88BUÒ\1aË#wüHéOn!Ök\8e0\98}zÖ\97G\14Ñ\16b]¾¢H«ÎH\®èHZÛºuEÔ\ 2\14\0\98\19'\12õÙÞ\92\97l\1c·*_)\ 6TEòÏT\8cÍ\15h\1cûàýó!\#²íÏ#6(C'?¹tóüÌ7\vçËwÓ\1e\90µápuD÷串j@æTÄó\93[îÏÜztÌf%Ryç^P\b°cV\91 :\ 2ABØ3ÃG_Ý#kwìÕ\118r²\8b¯\vB     l±ãT(æøQ\81B\11Ã\12\87ôXñij\98'Ùf?êw\rY¬È=\1cô¥ÎÌ\15\9fçà\17\17t}-\13Å°bE*$@ooT\98\86<3"\94\83¤ÚzÀ4§_Ô\17òW"=mÕùD?ÚyôA5¿ißñ~ÎÉ¡à\84ùÉ%Ìz®\8aOn¾Y\9a\11Pa2\8c$\14\9f´E\946º\/¡AÒÈQ2\9a\8b\95¾Gιªø«\9b´"ÅûQ"\93\e\87\9eÜ\96]`ÕTSd)\9e\10èP¥\8d
+N\98Ê·\83\14\19\1f\ 2Âê<Û
+\9b]{Ï7\17]\17°P\89\e\83\83\1cÜ\97£\8a'\94\18ðumá\85g\1f\1e\81&\8a\v\-ý\92æÍÓ í~\81« Üîæ¯%\1c\ 4¨\1fÍ\17\85Ó_»F\81\1fK\93آ÷ÜÓ¯{:\ f_o\ e6ÉÕ&Ä¢\8af5\ 2\90bÝï\v$+¬}\87¥Âæ(\9f­¶÷ë\81O;&ÐKlÅ\9a"'\17Ù÷zìX\9dæá\16"ÙwNè Þ¼ñí>9&Òo_\1aTì©3.P\97Í\80o\8c\v¢yËðc\8eÍ\8b\19·¡
+\14=\ 2Õ¿\8cøÆ¥\19³n\111Ô1ø°åNÓ\94\a\9e\9f\91\1e\9b­\88»DBýt\92\85ó\80#UßV\86\9f\99@ªÔ\8cǧBï\95\81S7\ 3ß>9û7J\17Ð\v\90b§ü4\1fª>]¼>\ÁÉÏTñ\eóõU\0æ\83\99\1d\14 ËÖá´\920\89I|ÀRnê\19Dv>HÊVzdaSþö¢°\9eI¦6X%C9Ä\ 5t0¤`3\11GC)¿ÐÀßLfÈ*$Åxý\bÑMåG¡EÖÄ\ 6ø![\ 6YÛë¹Â\ 2Q+\v?\ 3Þ\ e%\12ï\erW\14Ù\9a\r\ 2\8cgß[¾r\19ò\16² åÞQ?»ö\9f:âÁ\r7)QGî
+\16(j\92\ f2W\9cîàÀtÖ_\1c/(r\fÉßuøÅ\96?q    ²\0\9f®\1cÍÛ»¿FX\18~ù%0þ",ú\8e¢Ý*+T¾\83\85.\f)?\81\85mEH\á°Ùl\10ÿ\b*\8a\r\9bÍ&\80\1e­\867¦¼\e\8b{mlI\8aÍ\1d\84\1aü°Ðn\ 6å\8bå­{¯bì\f\8e\98\1c\90ø)UÌ\844\9e\19    `\ fR$j\85ýbÜÿS¨ÿ6^\10ä]l\9a\15c7Ç[op\1aêâ\7f\15\86È%¦¹\b1\94É\86l?]¹\9e\90A\86\19ØRïûýè\17à\9bmu§pÞy\13&}-jo\18\f¿\83\17\95\97R\1c\810t1r>I%¯Ý>ä\82ÉEZs\1dgK\17\97Ã\11'O×G\ fne¶q"~®þ¾ÎØÇ\ e¢\83Ö\19ØÅî\17\1a¤¨¤\87üY<úUßüïV\8f»Û¶H'×öú\18qq©÷%U=
+v\83\84Ñ\9c¯ï¤
\18\9e&0Án¸-u/\85@»CªLnFlh¬ì\1fo#Ïþ\ 1,¡í\83<\r6#\ 2\1d\8c\86l{#%Lti\1e\90óÖleLJ\85\vc\ 1cNaïÉ\8amu³\ f\11°\9a\1a»-³Qö\1a\1eϾ1èÆàYh\1f)ÕßyC/\98\94`Z\8f÷ÿÍrò\a«\891)ýËåä\ fV\13sê»EhÈ0m\82ç_W\82Ñ\12íÚà\9do\8aõµ¡$7áSÞôA˽6ç£nA@c¬\85\93Åêÿk³H\9c\96®ñu\9fÊ¿Kª@{A\80\7f"Ô¸A@¨¹?Îh\1c&\v9*ñ\ 3Nö]\ 4\85}\86VÃÒÛ*ñiÁ\ 6\9b\85\ 1\9c   ?¿Ë'Ú\9bb\93¯´T\bwÈN\1c\9c\96"¿-\15\18Ï\fM\an    \90\136´>@Óÿ\93Û\9aÿ¿+:¯H¹µ{\ eéU\83\ 1\9bÛLá\14\ eÏ\13\86!Ò±ò=Ûâ/K
+ëÅ\15&Ç76\1c\ 1¯õ#5­g+Q®å`ÌMµ\19\98\ 3\98\ 6¿çU´¿v\8a\8bwG
+\14\1e\8d®Þÿ\b\83¹aÈ}a]"`\11©j±[\82¤\8cÅ`(¬£¯\ eëâ\16ìdj¶Ý\90\86\9b
+¶ý¬R¤\ 5\85\95ßÃ7.   eø\11p*òî\ 2Y\19u3Û$\8e¬ +2H&¦Å\82P«rÕ¨¿·-\9b\8a^zn¾Vn´\15É?»^tV/&Æ{\ f\99X_&U²x\bor_\95ùéA²\99\95\ f²ÿ×\92\9fÜ·\90T¸ÓiÑ\8a¥J\9d,\12\90&³é±±Ý\89¤Æ\88o6Þ\95\83\90\17b\17\81¤\82­/Ç\9d\ f\ 6C\9eI«¡ÛE3v\f/y´\8bÉAîô\È+\ 1\7f0\ 6åª\ 3ûMp¶\83îTW\94\91ß±0,}áØÉpÇuj\84'µ \1aKh~Ì
+Ź­:W\8a\ 1Õ0MÅ\99\9a¡ó!©p
+\8cq\8c}\8f\18\87\9cÁ\94·ü½cögÙ\e¥y\ fê\80\10c\7f\9b¿/\92F\16&\7f\90½6E\8cì\85Up¯\89˯%\r¹¯\85\ 60?ÈGñ\81\9e«¢-Ñr½\84\ 66ËQ2\9a\8b\95\1eÙÖ\1cй¯ÙûBåDu\83HRTÒQ\86Ü÷÷ªg^íQ3ìÆWµ<\93f[&x\r>ß³¤y³¤$æ\9d¸\19\85ö\8eL8LåÛAÔ¢\fåâ©ùØ37qÊW#Â&\§\80ic\87Æ\8e'7\96Xn%?äÑÐ=\0åu\aw\14\86¾[ÇZÜâ\ eª.ír\ 3\12Ì\9bÑsty\12é/ïg\18\at¿\1eø4ûuQ\87I)Ñ)\1d\1a÷½\eS&Ø\17y.\ f+\93\11Ì&i£àh~yJ\90ï|ÌÇÔ üu\92x\160Å¿896ÛòHoÛå@\88·»a¾\16¨ê|½I(\90/îÜGBXS³\93}TÁ\rå5"½\r\8a\ 1cب#\12¨Îlã'å\93M\8f«¡\8c\9c\9e\9e¤\ 1^Â&é
+J\ 5\9fß\87\86\9b[î£IBw¯!&\98ç´æj,~\10\1a\83&Zÿ\92\89\0­ÙÛ\9bá«ÃH\18rm×ù|\93\\ 4\17ë\ eú\T`ã\13âÍpèîÊë ß\ 69Ödqë¯\86Ê©ÒJÓRKo­\ 4#]\90W¤^>ð\93iwtqâÉ\9dþØ\ fÞÿ\8a¨\1dH\94§éÊ\ 3Iz>ô¯E}!\7f¥Êzz)\a÷}
+*c\9câ\eqå#·=\a¼\ 6ÝêZa¾E\91ó\vzIi\81\a\99,ÝÍ\89\9d}\88\rÚ\99âZ¹Ì\7f(¯®%e¹%ú\ 4¾Ã\98\ 3*\98P\ 4\15\10\10Ó8*Êè\8c\19Ì¢\82V\9d:\17çÙO\83    çsþpc!{Ó¹W¯Ö\9d_@\9b\8f-H2}´±Ã«(,
\95\ f\ eov¡9+/r\10\85þ¬âxN8\8a\14·­¥\1e\9aÄ¡ÛÉÍÛã}qåò¤ °\93\r\97÷¯jÈÌ\8bYt\8dýì@Ôçh\8cidù*M²\a;ó¾ZF\ 5h=B\9cML¦\99ô@yçæÄ\18åûêÉ÷#\9eÄZ÷K0÷\87=f¿l\84 bÏÅr§KÖßï\87ñ`T¡l«\92|\ eO¼*\10bÃð\12\93&Z\16m\1cqó¦\ 1\13ù\ 2\15WkE·Pd\ 6\v¡H/Z¢'\17+3\ 4ºa^_aBkº+\95'\ 2Å\9d\0\12»]tVV\17tæ \8f\8aËä\88üS\v\1f\ f\86¬\A\15},ÿ©§\17\9a÷,\85*më;$\9f.\890_\8e}²wOT\ 2\80\927\98F\91mBu¬}tw.\9dm²óxåÌE[J\84ξ¯76r\ e?\12î\12´"Skû\8e¶v=2ñ\1ad\7f\aÓï)üþ-ºT\87ã[¨Õ¤=\1cbãÌ\89CÃàÂS\81§\82\1eo\aj±wdw\8d|êÏziº`|mú&S"c\ 1À¹¤\17¨\9a\84rsI\87e\ f\9bïl\1dX6\ 6ã\92WpViÝ=<qó½\1e}Q°\ 4LÍE°X¦Ü\9fBq^H<Ú线\98ä \r\9dõu¡X\82çs½Ââ©Í\92+å½*P\f\ 2Çû¸Òçgݾq\17K
+\81²"\9bËå·\89\11\9f\9cJ\rÍUá\8c<\16@ë²Ã\8b%B\81`&¥\932°¢Ò\9aiÄØ\ 4#u\v\e\9aÊ\1fÜö^¼Ñ xRP[\141#ÜÇó\9d$Ϥ"Õ¦ \14±?µX\97,C\87B\z9\93\BMãg)\r4G¢Á\17Áò3év]\80\1cô>\98=3\ f¼Ö\ 2\91¯f~\13\11\0ö\84-²u$\ 1\93Tò9ÿQ§>\95ý%/¿\15~ÈÍU\aRB ±\134±¤1X¼ 4¡¨Æ\18?ëé)\8e\16\ fÇÛåðÞ$tø¥\90J=zËh3ÿîÊ.\90\¥_±E\a¦Î\80ݦi\8fµJ@\9c\9aà\vÞè\82C¡³\89\17­ldNéwO\81&E\82\85Ë\8eX\17\83\18»Ý\1eÆ&ÉÛ½ª1ÛØ\9eòS\8còÛ\19üU"~9`¶\13\95\97\16Ý\18ÓÚ×N\¸qTnLis¾[m\9f/\96\16\1f?sá\ 3Ød\9cºÀgZâO²q\14[5Øßü\1er¾óùhý¼Æ\1f\ 5\ 3¨\ 3bóQ+Ù å/8\ 5)óHÃ\8f@\0\87\91¿º\97¯C\eV= Y\88¾ÒìðÞuË4µ\15\82v\ eþSXû÷¾3[øX|ç\89±5P\90¼Ñ'\1eà\bhiº\94\v4\83=sCyGWî,u%´·KÂh\8bâ\80\91ø\96N\7f.x&S2Nl$³\8e\b\81J¤[\8cuv\ 6©f};ð¹\15´kÎ\1fw\16\8b41¹0S\9fÑòÌd¦\87\85m$X\80ÛoNDàz{\8c\9c\9fUý'ôîC\1cjûâBmoEãðâÇ\18Ñ\ 6¾Ý\16\ 4z\ 1EÞ>KÊß×/n-½V\1cÌ= \ eå#Ç\81\8fPu¦\1d¦!/\8b\90f×b\15'?;»FL&\12u\99\84\10ÿQ^0\8e4\95Mn\14\ 5ïv\ 6ÝLºP\14\8bË/ÅenX.\9aj&\86\µJ\ 1Ê÷¤Ñ«Ï\80\8f   \13\1fO\93\83\ eÐÎt\13Áâáã\fP¾¿\81\99;?0­mJ~\ 2áÉ'm\ 4?]\µ\92\80²w³\87W\80zA\90<þÑOK£³æðÂÍb\8e[¤p\17\15>\7f¯ðü1ÄÃ\16\14:
+\940»Vã\1d\9fîÐtä+\8e\19×¥âÃ\87äè´\8b\83%-e\80!\83bº­ì)`ã\aÏ0r¯o>«(3)\e\9f\84>Øm$&\95\9f\1aäåÄÞ£x½ò>\9c\9e\85ñà¼äÊJÙoíF\11-,%­DØ\93\8d\9d\8b\95\8d9\1a\91\9d\0£M\17Æ\1dÛ\9e$\ eã;k\ 6fWÃ\8aÂn½\ 5ÿ³Ø.\90×á\19\ 2Øó\ 2¬5Ï\8fÓK\8dÉ\8cÔIK\8fØ\11\ez]\ 3Ïw²\8d\94^¢<\96aD\1d0\83Á¨÷ã5/Ábý\94Ä\85\8c
+÷ª,\93   \97My¾\15øbõê\9d\10ý\16ù[r®\f\8f\a2ÅÎ\98FU\9cÀ\ 4\ôÌ8Ä\9fLjº`8¨_äDÞ¯a{EùµWà\89ý\8a\1f~.;\08\91Þ\8bëc¼ÓøZ_\11¦&|ÿ*[\b\9eÈ=?Ã\83\1e\f®ÒZ¹  \9b\ 5\9bìGì\9c\18nÂܯ\v~(gO\9f\8fô2\v6)'"¶ì¯\86á\ 5#qF\b?V'\85Ü7§\ 6`¹¢bÏúîRB9è\97iv\93ã\ 6«\9eÛVhw9éî¶&ÁÌÙý&"Ñ,.i%Â\95·EùÇÈÇâÍo·\10¨²\19ÈËG?¼·ùo\ 3øÛØ2\91aeî\9f)~*ñ©\a2>iî\9bÄAT\0z"{lê*'Íw\ 4-7\11\9fÃ\9b\96\13\98bÇ{9\97å'ãu\98Ñ
\ fa\1c\18ÄÍføæ*Î9ö0ï&{4$Ë\r±\85g?;SðE\15®\14\11\8a\16\15l\ 1Ù\a\9a\17\ 4\ 5ß\11\9b¯xÖ=ÀÉî\80\18\ 2\92«\93hz÷\9d[¥Ó¨1O0ú¬\1cC6Ù\987\96"F\b_G\bè:$\f=$\19ü,/\82¨\8eïà!:ü\97\87XȺÃ\v\96\89I\13a\87\8c´\9c\9dL\eÿ\97wxGä[\80)Çâo\95ýô­q8­ö\9añÆMN\93à[\18NÓétê\r-k§\17·Ú«ÿª\97\eú¾?µÔÙ^WTåò
+rT&F¼¦pûÙy§j'S¨ù2\16\e±êb¥Iê\7fN·3\aj¾·¿y˾¡L»X.gR\1cÈUTS*\92O\8dÓH¡;E1\14©#HayJ\98Oñ$ÕÌ&î\aÍû\93u@&
\89\ 5ÞPÚ\88îVnb\12þüý4\8eäZøÒ\19ÔuÌ\19\ 2Ìwx\9d\11­9u"³¨Çüyw\86\97ë^4Q#\9cÐä\aoÒHx\9a\96æd¡1Îcâ¸R0íÊ\¸ ª³g\1e©×d®Zv¶o§Ü&\8a\1a)\91\18\1c/³j\v&1j,¨ìà£Np}®°$\v±L\94\rî|íâ ¼åø¯12\89\ 1¥ÐRÎb°yUúo½\ 2\aéhz \9a¾x\9dá\91òå\fÇ\85¶3 \1aaóïK×ò\87 u\0»+»«\93\93\16ûäîÅ¡#<µ\ f\ eï\1f\97FjÑÈ\b\9a\14\ f\10=\ f¦øb\96\e\8d\87eú·±È\80æÌ\19É\97\9c¾¤\117ê7±\99RB&Ýsø[Ú·=Îr\1c¸>\8aÔ\f]'\8d¾> ?\1a\18\9al\aì\89°\94\96bßÉÏe-üRé`Á\8a¿*ÅãkÔiÕ\98]í]éT\1f¢\88üZé;\etw\ eÛÚ+¥\86{\88³?\94ZZ.jÅ|óÿ¬WéZò<\10½\82^\ 4K\17öB«¼ \80\1fPÊ*È&È&*n¨ì÷ÿ%-%]\92RÄ?}\94´9\9933gNâ?]<¨èë\ 5®\9eë5,¨»0\16\89 |![¹¡hB¬\97\1eïÏÚ\97"\80öÇ|áõ¶\85\a\95]×L´<i#P\90}\ 4+\17cm"Á±\87tûQ\ 1\ 5\85ý$\19é½_\ fwé*\ 4õYsÊõ)Z\18|E}\0V\X²Zå5\82\e,k\ 2½¸ø\9e,I \93õèý§\8d@\ f\95¬ÂÞL/ã\ 5o\14\v:Î<6I E¯À]\rñ ×®\11Eo<ï³&>Ö»\9c/½ò~Wq \81«¯d\9a\0zéñ¬v\ fq\ 4
+jÌ\90Õ\ 1_¨\7° îÂw\82\16oów8P¾°ø(\13A)\9a©Õg2>V±?ãå;Ï\ 3>ÒÛ{\9e\9eGº-\0\1a_\9a\9b\86\95\1e´\1fâ@^\8c°\17«y«©\82JÃyÁ\0ú\90æ«¥\84\0\96H\8bóU\ÌfD\1c(P\98ê÷ë\fÁ\9a@ÿÕ¤ñ\13      tÌ׿ê-<h\85\84Ã\8bµ\ 2JÑf\82[5!N\ 4­ÊbE$\80\ eD¾]jùp  ÆÜ\95ݶU\95\aq\¬|\97ß~\10AÛ³ÛÈ;  ´ÄwÇlZ\ 1\855f\8aµ\9a\9cë6\83\ 5½\ fu\19"èý\7fÜ\95\a\a\10ö\83\7f\b¦Æx\82oK³O׳\9fÃ\82\8e\9eÜ5"è<ùÅ\96\15P\8a¶Æ:Ìðãñ\7f"\1e´\1ep/ý '± \8fB\8fÃ\81\ 2M\86°îþØ\1fÁ\13|ír­×\85Æ\1c\82\ 6,MS\8fÝ\ 4Üÿ®\9f\ 1hreÖ¤]ô§«\80Âù2OøM±®&ñïµ\ 2\1acÓ\Ñ8i\1a\81äb+AРµSÛ\11ºþQk\ 2Ð\9b\r\ 2\ 5(J¬Òí\92ßǺÍ\ 4LRHóÞ\89Ú4±Ñ6Y6ÊÃ\1d/I\9d\ 2\ 4\r\9b@×»Gà]f\\1c(?\80-ìÌR\98\ 2×K\154\13­\84L îv¹­Ê\83\90éT«zÐØöÇ\15Ëm\9f!(\8f@\ 1\8a\1akW\18~öò×~\0Zv\99 ^¯¥\80\1aߦUW,Qz%¯
+Ï¥\10\9aÈ\96u`À\16_6«\rfM\å¥ë\97 ¶Úú±*Lõ¦8ÐÖ»\16\81¯6Û\13\9bÕ\97Çgܪ\96ý\9aëë\8düuMô\86É«õÝü\93¼Úê&\12\881Ìú»\94%¯¶\9b\8b:qu½\rÆ´¡&÷1\9aÜíÄWÚúÐÜh|÷-·#¯Þ{\e^ܪÆØýå\90³ùºø\9e'¯>\\f\ 2äÕÑ\9c«#ƬëcNìÙ¬¾\8dgÄU0ÜÓi´ja,*vCSòשðk\87¼\9aM\88¢\rcÑÛ´° \7f]_%¯\88«If¹\98\10W]L w\81\18\9b¬ÍëÞZz®­>mÌ«1>ÿM\\r\Ǫy´ja,p}Õ,\18¿^*\82´¿ñ\89AÅ"6\ f×>Æp5«ýà®fèfqQLµóóh.\e)ßç=³r+\9f        ´ÚÿB.f\aþ\92\e7\91-\9b\86\85\170\rÜyå3°\85\87=à¡\v§'ò\91\81\12pK`\1ad\9a¦¹¿vÇØT#´¿îtû\r]¤i\8fÀ*\17Iõ²\93Ì\rúH¬#µ\7f?,\1fIõvÊe\a\90ñz\8d@)\1aÁ\82y\90\8c\12\ 2ï¯\11@Áe'Þô\8d\b ý¡\92}=¬.Vwa)\90AeÏC\87\bÊ\96\9eÂo\1a(t\17zØk\97O\ f*¶¼z\82\e\171\1dè\vÃxtô²q\ 6\15©`\0½\0\ eÖÇe\ 6_\bÖHð\88\fê.LÃDPåæ\80@a\8d\19b\85w\87G\ 2h\7fb\ 3*{/\89 `"û\ 3!V`,\80#\99\92@\9b6ôÞVº\86¹o\8a\15:\12cV½p5xø+´7[þTÄÑ{B\8e7ô>éMþÑ\9füÏÁ{\8aQCj\ 1\8b\9aZZ[\97UØI'\8aÞO¥úÓ   ¹\97\8b±\19¾\ 4\89\11TfÑgé \14Ô=r!\7f\ e\10\14ýÙk\92à½\ 3(à×&ê'@ë\85/\90]lnÕs\83¿\80\9aÈ.IAFÒ¤Áw\1aà_\ 6ú­\9d_\ 3P\r´
\9c\ 6äE=O\83Yj/µn\94-\90ìñå\v\9aF\8fô\92{iïý¶²\ fj\ð28æÍJ}E\v\170v8r6ò>ËÓðá9°ã×˱\16.\88`\90\8fN½lñ@`LO`Z¢÷\8f`m¡àÁ~!\1fª°1\1dÊx$O4Ø\89\ 6ác ð       xèç\ fçª#Êaö9©r\8ctå1íåáá}Äø\ 4ïU¥\8a\8b\8f¢õ\11Â\a)\83ZþX·\83üÁþ¼G÷¡ý|1E¨X_[²\1cç\8f\9f}κʬtL\96Ýf\9bù=q+\8avPî\87b_D¥ÑFvZY¨®\8c\13Y­¬«ðéÌ\13x\9f¬µJ>\9bù×\x`Ï;eC\96Iz¤aÚo\94\1eÉ,=\87èMÒC\1d-Ý~pm ðpd£ôÌ\1aaF5eVî$XcóDÉæ<\93\1d\v´½\16<pÇ\11¸\eK±Ñ.[ÁÉ6±+Å\ 5\90ûôÐ\fSL¡:\93¼«\1d£úÑÇ(=Dâxyè0As\17Ø\9a\97+Ì>û\18\19\95\86ùÐI\ 1a\15FR.\83z\859´¡¡Î\19øh\12ÓÄ¿FÝý½ë;\87\18»)\9dåöE\93ªEP%'WäͲ\ f\89²\83Í°[AÞA,¨ï¦n9`ì»\82Ó¾³ï:XÉO±\9d}.#\1f\9edPyìUPv1ز\98º'n\:\ 1\8a!¡´\9aPE\ 5ýÿ=I\98Ú( \15ÄÔÆ\r?Ûv"¦s)±\b>ÂÉj1b\90\91÷E eua\96\94(       ÙßøT§hH\89\859\96\9e\17\99¢£þìg\ 1?\98\8ezFýËó\7f[âX¢è\93ò\v\ e\9dî\9e°½/\9buÚJ\96_?xÉG\9a¹É³òæp\1e\a\96N¶3tõ¦\92:\8av\9aA¢¥Ó<\85½ç×g0AÛ\e\8b\13ò×ÕÉö¾\92ÏØì\88áQv¡h\87\9bEΠ    RS~m3þï\18\8bþ%c±¿dL8\8f±½ÓØ\17ZÐzq}+ò/ìT:Ý\1d£³Bo        O\9bí½Ø+\87ÎÐâul\9bq\1dÓ1\9dÁÆwå[Ñ8ãÏéÊmÆëÀî+\8f=;\r\96Åf2ÛÛÒ\88\e\10˯Øa\1c_>\90·4³ÃϦ\93αKÚÞS`\8d!\88e\129Ö/\ eÒd\7fÅ3\1d\ 4:%üQ¢'q\82=\88Å[þ\8a\93#\9d\8a\ e¢0\ 6\ÑÔ½\951#ª\b\9aøiã´\91`\9d\aô¡\89Á¦²\1f\88E­~.¿\ 6->ÈéN;Ú¼mO\ 1ð\11¸û,\ 1\ f#\8d6²sù 5Èh³r\13\8fDÑ'\1dê\97\ 2p¨±ÃëÀ+\1c\19Ë\8e\ 5`´å\18²\879\8dt!Óm×ì)§\1c\92þ~d"ëÚ\aãäµ\1a\ 3\11\0\9b'w\17\7fSTü+»ê!e\80óŦ!ááÅ\ 5V2Aío£S/[tP\9fÔÑ\fnÞÅsÈÒÝ\92J'·¸\ f×âû\80¢å\8d©Á)Zð&\96;ÒÍ
+\aà'dã»llpÁx¯D\14Ê\15\86(\8f\827ÉymO\83½Tè¦\18\92DzÙÁ\1f²¡¯\rå1íåí
+í»\8cü»ZÉ\ 2¾:\8e\84&rÇ\89fࣩ»%\99\8fb\1eËø¨|\8c\12\15¾Ø£å\9d\84îÂ\9a\ 1%VÆQv\18Ð\86:\a(³F\98Ù\e\14+\ 3\94áÊ)1DZ\0Êk\92{8F\8cN
+\92+";±ìC¢|¼\92\91n> >D\91ÑJG¬VzY1Zi3ù\94\133­æ Ó  x~ÉÝÞ\8f)ç1\ eBk1Ø9a=wÉ;ÖT\11ú»ØI\83\10\84\96<¿_\96\15ã\füM\9dg:´ê\1dA\8dÙVºm\9dW,s\8f\10\90êaH\95\ ejÇ8ô~#\0É;\17ðc\86y÷Kb.í\ 5\80²\8c:\82\97­X\ 6ݱ9¤ó²Ð\8f\19G]Zn|Ã\97\9aú¨ào¶}gßu\86J\ 6"\1cp }¶\15\91\ 3i\12ÍʧsJGæ\9du³¤\ 3\ 2i­_HÆCÛ,µ=S\93{-Ø\95É»ÚYµªdÍväQ´ó}\8c\17ÉSN\ 3gåa\9f³;PÝE»M¢]\90&\9f²Ï©sOuJ\84ÍráÁo\87¨*\14Z        À¹ÿ9ãL\8e\13þ\16¶ï\9cÈ\87'\19T\1eû6\94]\fN\7fàV<E;iÃãã\ 6næ'\8eAãÜO£Ë\1eÁD¤åÖ\8f#*õö3`\9cbfEë.¬\8a\ 6~;YÑ\ e·WSü\9byèlE\ 3\82\18o¯'8xëfÕ#W\13J§iö\8a\ 6\16\1a®³\9dR¯ó\17\8a\ 6²\86Q´Ó{\1fîsª¢\1d²oÜç\ f\14\rî¢)\9a6+\7f»\8f\8a\8fÿ³^­k\89ëPô    x\bZÊE\10\8d\0\ 5\ 5\ 1Aq\10\8e8\1e\99QháýOÒk\92&i þÉÇ\87¸ïkïµÚUÇÊÍ­;>\99\88Bc\ 3ø\11êû\88Eº[p\e\7f\9e\9f¯û9{áÐ9ÊÒF¥\13J*í'ôÃ\ 1\RÚ\16{óhɼ/£¥ª=\e­0Ì\f¶3O\ 3\95[¯Y`¬°Õ\92\85\93ÌZ³À\98\88h\fX3Úx,G\94°\ 4e`\9e<\91\r\13lG\88Ú3­\80\l;£åwd5&i¥i\ 5ôeK;\13\9d\85\1c6%wÙ\ 5i\8c\rÃ\0~ï¿\85ã\15Ä\vy\rÇ«0ü\1e\1dRUÊ\85W|u°H\86ü\ 3&Û{Lä\1a\89$Êïi·\10Q\16ÐØL\ e;h\ f´[¸ý\15\ 3]ãò{Ñ+\ 6íìÎï\11+î-\fsÅ \1d?¿§Y\89(AvÄ®!ÿ\16Z\eæ!ô5Äoá>q\v-/ÃÐ×ÐÉ~¢Ón¡{+3µd!Qéfì'\88\v\80¸fÅ\vF\h)M8\9a\93\8f\0\128\9dñ\19¥\bÓµv24ö.\0H\11¦\vL-b\84)\ 4û\81»\16¯\98\bÝu:inK¦"\9aèB8·\8d1xM9\99\ 5Ûr¯öѤoyt"r\81"\r\84Ä\ 2©9ÉÁð"\ fÓÌð\9f\1dë,áºRà0Õ³*\93=åÞ¿Ò\15`EËX\8f\9b½{\91Éüg\86:\8d%.\82K)\0®\11ÌeqrÉéïd\93À\8d%\99ÆÒÕ¤ÖaöÅ[\9fqkyBc)\8e1µsµÅ:âV¬X\1düì\8aS\8cY1Åêd.â\ 5\1fh\8cA1
+µá\84Êô½\89\80}±fB((Á\89 Áå\d\vº6,`#®\8eèʹbÙ\9cqpqôöôvÔxl\ eîÏsëÚ\95¦ÿªL*?\e\vµ^˵\1f\1aò¼}ߨ¦ï\81²8Þ\8fÆ7às«\a~\99¨7\87ãæk!q&5LcÀ¬\9c@Bv>Éð\9e¥ÀÊ\944ãøºz\87\ 62Ñ%\90Po?]¹;|7äÁ¨gußÁ´\L\0Ûí¿ Ðã\8b³rýiä\8dW®{ü\99Èç*Ã\8d®\97RÃlñêí\94æTß¼\94UÂ)T¯\8eÛ|3¿×e8=\94cGw©g\86ÓÑ\98éÔ\90\9aË"®^±\ó-ù±Ït\9a¸\9ce\7f;N[\7fP§§Ñ\14ê´t\1f\ 3*       )pï \808}\8dÇe¤À\89£¸î:-bN\ fÞSÉêÓ\1fºÓRê9¢\10n±\§Y¦Ó|³sÚc8=\94\95ÒuãÅs
+rÁ
+<á8mÅ\ eÙN[·ò#ÃéñEDQnþëN\19¹\8eîØN\8f¯;\ 3¶SMë71v\ 1ÜÆàß3î'ë\97úf¯\92ûÏø]±\9eçÿ\ ex1}¿ì\95\7f\bXL\97¿Ö\9aG&AΣ\92õ\1f~à&<\82é)\8baݽ \94\9c\ 6ª\9fÈ>·V\94\83&PÔ\83\14Ü¥×\b\1fk\90\f\16%ÝÖ)Û\13¸×ÀveIcÛ\96\17:¯ÓÆ\8b&eÕ7 \97ÖV!¹*\89\fª®³$@Í&\86È\82g\91ó^ÜðX\9f}P\91[Ò>P\14[J\80Ç\ e\8av\b¬\90®6Ü\90\94\88(ÿm\90×~\9bÖ9\8aÏ\ eê^ú\96:}ág\1ev\9f<ô \1eDr±G uÿɯ\93W%G¿p\8c\r¾Bç\a½\80\fq\99VØ=¿ñ*\0/ÂEÇw\84HHö­ô\a53v­\13±k´ñÙ\9e\95˵kB#w\8d\9f6\ví\1am|\89À\1a \92¡!ã\16\86èdù\97ÆY­VÙÐÕjb\1f[®ÈÏGûQ&35×\83÷Ø©õ\12  Zj@ñiã\91DhÚíSãSwW\8bµ:q¦\ 2\ 5\814Ò"YÍ{Ù8\8dµ[Ý×|àÛ)¡ü[b5\14PI©¸¹\81\18mÊ,9\9cß\93!þ²`Û\12\14&@\88\88Ê\10h
+Q¹ö\1eÛÊ\98]y;\8d=\8fD8µ\9b6ó¯\89©æå¼ëNnn%z-T²dï´YxÞÔ:A\8d\80\8f]\9dÒ\17k'Ï
++\1eIB\94\Æý]\9a\19\17T\86OD\92\1e\1f»¹U3}5ã>Ö/Õ©´n¹\16\97\98ö+­ ¿;4¤Å±\8e\8d\8fM&@Ŷ¦\13 «!sc\9fÓb5÷بAéo+\98v%ð*²ºûÚ\ 2{\f\ 3\1aå&ñx+Z¬\93(­Xö¶´\8bU\99%\ 5\82\1eOÚô\90xTÚå\96hP23(¯ubý[ÄÌ\9f ¨$o.ÑAvÿªåÛ.¿\7f\11\83ùùtÒßq\18\bc\1fóÁ÷LV~n,\1eìI\ eo\8c¸*á*ö¦J£o«Ø[9ùøM\15s7Ún\15+eîP©»>[\81\83òTG\86¸6üeà|lG\ 1±>Û0qE@=¢0LTÙû\820Á2 \11\17\99b¢7TÍ'\0ݵá*& b"\ 2bïB\ìù©\98i\0n\98 \ 5\11`\ 2dÚûË\17\b\16^rLZ       j2É\85ìÐ\99\ 1îË^í£)¢yè°ø}\11\8c}¨_\82ÊA\17q\94±g\16\ 3ò1Árð\98\vL\bg.xB\90]\10ò\8aÃ#÷ý<òã\12ç\91Ô\92G\14\84G2&ù2\98g`aú¥\92Í\94
+ÏÆJÚB®Ò)dº\9aÔ¨×|'>ö¼v$\1e\17ñ\1eÞá$³ê$\8cx\9e¤\ 4!¥Á\15û\8e:5Ö¦¸b\8e@Ä'%Ø#@\88Â-BÂô\v\f\9e\8d\96È*\b
+       \ 5³À\15ãÔ  \17\90lÅÇ\vjÆä÷A!Y[\aì\bû\8a\15c'\8b\1cüÇk×D\eN²ÆÕtØ\8c\8dö\93´\19+ÆÊ\92\84Ï\98\9b:6øqkðé+ìo\9b£ã\1cÑ\10QDd\ 3@N\1cô\8b!\aÑÞC\83\8fË\94¬äÔDèÔ\8aÕÁÏ.\91\9a5c\98âmYqS¯\ 5èß*/\92Õ¼\97\8d{GËbJ7XÏqðí\94\10q?M]\89ÏÎK\1c\97TÜ\\1a\8c6µ7¸Pô÷\1c+\8b«Å|\859\10(\f²\ 5¦ÒºE\ 1\ 4\9cÈ$Ëô\8b\8c\93åj¹·&Èr±ÚW¢¸âó9\10\80ËÉ\ 29GÈqÀ\13î@1{É]\0"B\ 3T줵ì\14\9e7µNP/á\13°AË·IZjèE¦M:\99\1aAw\ 5ç\13¿/åÛ(~ô\ 2&\94:\9f çE"!tÃ\b'tÖ\1a\ 2®«\92\10è.;¤RÝ\ 1¸ ,Þ²\ 6¹°\vÃà\9bxu\8e\84&\99\85ß%jñ%\95ô\93×á½è¡s°Ï:uùùt\92Þ~       ã\9d¬ÃI~)­¸½\94ÕL_ÍÀÇbõÀߨA3\ 6L\95\r\9a)0É,ÚÉb\1cÐXe\1dzÆ@½w\ 3\1f:C@kÂj÷1¼ìjÇX<\bDcn\18\9e\1dB4î\16\rð\12\1a\81V4åä#Ó\8a9cq[öÙ\ 3[^q\8cáò\91\1a\92ß\94s\91]²iþO~þ1O\12\97\ f~\97å#\87)³àN&`ø1\17âB,\86\87\9bÚ3\97\19äc·\8bYÊûO~)ݾ\98\8f}Z8$\ 2²5ø\93\vøî51Õ\98\ 1ûµ\986^4i\88\a«à\9c¿\89ØtÐV\16\10ñýïa\12\96©jRë\bpK¤\80)\8e1µs\15\1aû\83/\1a\83ß\8a\ 6À%\94\8e(¡é\84iGÝ«}4¹Ý\17´£=\e­\1d£qø\98ig\e\1aÏ\8c\ 6\17\80\ 5\%ejI{\80\10\84!\0\b\ 1Ã\8b\97vÕiüÍ­{]3\bö¹0\1c-ý0\ 4ßqaH\800¢°a¨\8d\90ªl80Ah¢2<\f\a\ 4\f\18\13\86\ 3Q\18òØ8¬wx\18\82\e\9e!@\88{ÙÂ\ e\1f\86BêÕ²\13\ 2\86\88\15\bÂà+\16h\a\87!ÕJD\84Ú[Æj\8f'm\ 2Ó¢*\ 1²q\93BÛÿ\93\0Ä¿\95\86\88¸F\903\95®\ 2¨4¶2\8e\96ÄÊp7Lk¼ú\86\92\1a¤^\99D\87b\8cT\8e|\9a\ 3ûÂ":ÀX)´t\ 1Õ\9eÇ\1c\95´û¦z0I'ßJDÐÎà+L4 \17ÛÎhù\1dY\8d©³Hj±`;\13æ58ÏÏ×ý\9c=C.¿\9b\96Í\93ý-ë\16°Æ7\16^ãsï_é
+@ \96\90\0aD\ 1xêe\b\18\82ïúü\ 3\16\0C\a\84\13Ý\ 4!k\8f¡4ÀÛTiV)\870\97\vÆá¹\ 1÷Å#\ 2ðyò\8aI+%p:\8bò\93$L\ 1\7f£\ 6½/ÀØ»\1c<r\8a5*f\{?f\1aÃÔB\b\95²HŪåÛî÷èÊ\89\9e\9fO'}A]y\87n~tq\95\93YÎ¥Ý\8e\18\82\90À"\1cÙ|\8c6\13\ 45\f$\863ÃO\fÁw.1\ 4^\82©!\93\18\16jÃ×\8dÀ*\88(èAa^äz¶À¼\ 1Ø*\0\ f¥\94\ 4\1f\9b\19A\\814¦~2ú\ 2L=oj\1dnÅÜÇ6Vúb\1a+Æþé\}\v\87©g\8f\ 4®&±\89½NZ¹¸½\9cd\85\8d1ð9¢\9d\vû<0Æk"8\11Ý/gÃÐÎ\83\87ß³\83î'u\9cí\1e\\19º^0~G÷?o'ÑÌà\97\16ÝÿQü\15Ýo\9fhQ `ê\11\ 5~\1eE3ï\1f?ás\1eMÿ\9bmG3\8d»:|\1e²Å«\93\98ÛÐ8\11²ýi¢KðJí§+w\87ﺡ*:\8a\980URûo6g\1c_\94¤BùÄ«r®{ü\99Èç*Ã\8d®\9fJqàïíÔõ'â¦À&\964}ó\92ÝGç\ 5s\9a>-ü\ 6x!Ü:N\ fe¹¿üóDwZ\1a=2\9d\1aRóC%\9cZ\17Ùr\9bo¾]ß3\9dÆÕöä_\96ÓWÔié>\868=¾®ÝÛWÌY\99qÙsjÈïso)\161§Ç\17g«Ø_7ÓÖ\1fÌijD8\8d(X\81+\ 5¦Ó|ó$\7fÍpú?ëU»\9b6\fE\9f \ fA\v$@`\90±¶¨\12´4   t\8cµ\9bZJÊ\87 jªª\88­\80xÿÙ\89ãÄv®cÖþ\89\90°ì{Îý:çä8ÿ{mÍ\81\99V\80±\1e¹»&ühÏ\\8cÀGuß8}\8d\1fEX\92¥\94«É\1eý¡\83\8fnw÷í\1cø(ê\97\8b\8eɪß\8aP\a¿H"JW\8fÏk\95sóýú\ fw.è\17îäÉñfî\8co2oüöJê\8e¬Î.Â<½ä\84(uI\vc-,Tw¿\85\87\14uS ¥b\15¬A°´[ýü[4W'v¼±Ó\9dªÒ¾¶±ÿr\19uÑ_|ï\b\92'ø,Ç6~¯\f\8cú\89ÍÚÑÔ\90´\82RP¬\bæCÂ\ 2\v½ªÁíBâ^QÞÜ]rõT\86\96\82þM\r©c8\ 3.¤ /0O%\90'vÛg¤\ ei~\90'Nú\1eÌSÄÒyY+\80\96\8bîx\83ª'¸\ 4êþ\9b?\ 2C¢j\­\9eêþnõp8>fòG\b«\9f\84OPãÿOú\17\85\90ð®T\bêª6ù\9c~9o¨ò\94в¡\98\8aBBåÚ.ãúüI+ÕÁ\ 3Î!s,ÝY)ÒæL¯·rߨ\ 5α\18ÚÐtÆæÎ\87}\0b,<îUs
+\12\10h·º\ e\8e`\9d\1c\82S\80öµ3º\eÊ­\ 4ÊÆ \18K`±_\9c©]QAåßÖ\8adY   ÓÉá\84?fLÌ\96\ 2 ú\8b¾\19K*'\1c(¥b0PB\ 5+z,Ï|o,ózÿ bRh©\a´ ,ÙöCîÔðe\r¹\93Ñ
+òËX\99P\16EÂÒeEBJ\9d«md¤\10V­ki÷êHÿ\rMÚW\ 6\97ÎxW.]k¶ï\ e²\12\81?\84\9dæßô\9c>Y\e®\8fq%Çÿ\9b]\83\ 4\95\8c¬\ 2\14\1a"\8b\e£I\907¿¨R0ÑF¦\82\81uªïÉ$/\9a\eA\18®Î¶Yó5\12\86Ô½2Ò0>\8eP\8dAqs\11G+\177\881t¼\87çXOºA2ò\e\1d~î±mf±ÓR\18®ÿ\ 4\18\0ju\13I\rendstream\rendobj\r23 0 obj\r<</Filter[/FlateDecode]/Length 13996>>stream\r
+H\89¬WéVâL\10}\82<\ 4K\bK0       3â\b\ e[\10tD\1c\10\ 6\10á ãȧ,\81÷ÿº;!é\ eÝIGøÓÇ£±\96[u«n\95ÕYLû<\r\95\13÷9#\e½O\15»SEUR·÷©Âü<\94\93eðÉÃUªpZ\99ç\8a\ 5µ>i\97ÔÆ©(*ÿ.§ñ\8cTT¯U%÷\10\17ÄTñm\93µ\8ce\8c[ô?\85s}¦gJ\7fÎ\eð£lîÇ}>\83{\91«2öXþØ!E\80\17VPÊ¿H^v\9eÂ2>û\9d*è¡\98e\a\ 4ç|\9c\91.çQó\93\9d\83\8c\19\ia\94\ 4Qy{©D4¹£Éð\19\0\7fÀi¿b'yg\7f®§\8aùû[ô\89åà¹QÜeßi©õñV\ 2þne\a,dE\10i`©/\93q'¸1º©÷\97.@ìHÆ\8cù#Ó\94 \ 63ö*­zGCìU\v÷\8f\94äk>þçh\88½\96O\ 6\a \96\93ÛX£\156\85\95:\93\ 6\89K½'\83ÙĨ\85\ 5\11:Pv¤ù¶¤3kSØò\92\9df\0"¶)rÏ\vF\fÅ°·\ 1ÀÊ\7f­\9e\86\1e\1fv\97z+6»!0¢ý´Q\85´äÏi\15ë1\87ÝõTQkÞxvD\12L¯ÛEa\99ø±¤\8c\87:m< \1e\v`¢ ·>¼+m×¹í "\88\ 4&cåÀ
+\15\f-Yz¯¹F9èdóï\85ª\88Ò\80v\1e\19´ø[÷ç>\15\f\90\v\ eÇp\15\1c\ e\12\8c,\r\fÈJú\82Ky$äÅs<!Ô³Ól\ 2äÂ\bêô\v\152\93Ü\85\94\19\19Ó\13\88Ã/\f±kH\95*\7f\8c-I¢F82>C.Ü1/.äa\1a¹\ 5µ\95\8añª\ fÙIð\13Luñ~m\7f´¯.Ì\86äS\17 $ÑC]  \9cÇ\ f§M<æ§.8q\92\ 2áä \ 4{\8cÀÉ_Xp¶À\9bæ\84dÍ1Þ Ü!q\8e\ 2Á\17\8dJç@!\ 1/fP@\ 3\1c\ 5'*\99Ù\13Æ\v§\9bÜ0ÐÈ4·Ø\12\ fêùr\ 3½´ñöÒ\1aäÞ·\1dÐ#Lº"t¶ØGC«\8e\fݦav\8f\86èÑ\9b1æLÎFóqbiï\18\r¼ØÃ\85S\927 s\9aXBv\r\9ec¢õLz\15ï      óÑÈF/\9a7\a¦\96\8b£Ô \17"9R\91ÄLEÂ
+ÄMazV\89\98`æE\1f) æä\16ÿRB竬kZîõ\8eù¼´Nb,]ÓØ[äû°\b\À¸8K\ 5\ 6²Ä
+8¿ra³Ó0\10\1dò\e Cìs\a"+Së?\14\14Rá¼\1e}w&̲      dü¤êáÀ\96PH\99V\87ó\1a\ 5;ÐÝý´NË\19yÁÛÁ£\19ò÷>ETþEò2z\\92Ûâ\vÖ\13ÅÎ7É»\96LÑíNÍ\96Ü;\ 5ËêtÏÔ\12¼ý   ÷\v½C\9b{Êû\vÄ\ 5\15\7f\8fÄ]ù¥\84B\1cCVð£n±#\9e\1eJÜ&ò2^û\ 3\13ñ\15Ð\0\1d\97\80ft2\8b¿¤þ\853R\ 2\f\e\94±¬ÀïØÍ \88\1c«n\17\81É;ïJÚ\93\1fU\v4\15©[)S\80O·"S£m©\89L\99j\9c1³àã­7¡1\8emç×c\10oíÐ\1e+\v\bÇøÁv \95¤_õ9í¤¾\18\rv%!;òQ²J»¬ì¦%i\aÛ%\93ðFg\19\b  \99²æ\18i\8c\94\9a\89\84kóAæ\80å1?¿ö`Îx+Á£HFÌ\80\e\10gÑðwp\85ÇÔü02®a\86ï.&\94³XFáª\v~Hz\88\b ¬ÉÓ\ 4´ýËñ\ 2~\97\ 2Æz¬´\7fa~[2\18ß]\ 4\92îð®¤1Þ\98»³æU\12\14S\1a\9f¶Ä\0d\9caÐXæ\bÜ\ax?\84¿(\ 3\9c+©×9\86\9c@Vº~Õç´Ó_\ 6\8aƼ+)vüd<_4\16     ±]\99±í\©/\9b\8ebu\91ïD\ 3\ 5»P\89ÂWæNá\95·EêR°\97,\8f\96\97\80\10/$Ý4¬\ eËÞ\0F\ 4\91\8f\86ýe \1aº\9a\1d]| Ý_¥\95z$\1a\ 2SnæøÏ1\16\r\81±ìáj\1câ=\8c\1cÚh]DBA<\86\9d=\1a\ 6¿^\91\9d\804¤n±îQhØÝÛ\85;\12\ 2¾\ 4\94öÈØÔ \19c\9a²îJËXNnc-\0ó\83\1fµ        æ\80ßͤIÕKJß.°\91Q\1dÎk\98\17¼½&á¶q(\80\8f\8eÌa]¯\84Ðñ\949\8f\1c2Gà\11:\961­yóÅ#\14ê±\1dÞÙb÷÷í\17'\955\ f´pÚ\ e\18³b{     `GK\96Þk\81¢±ªï¶sÀüŬL¢RÝÿ\16óµC\9e\87\19Ü\8a\\8a\ 3\16\8b£\94ò+Æj\ 1\ 4y-\9f\fð©ûÜ(î
+\7fw¯É\1dMF\ f\9dÑ\80\84æÞ·i8^ïÓ\10ü.0\r]$4'L\19ä5Ø°hHÈ\0g\8b\11\9b\e\872\1fw_¢ø\16CB`'\ 3ª²/\94ã5Y\17J\92\96)§.Ú'ÛØh[júµ\1c|,S¹\ 5\93\95ãu6zѼñ3ÆÐ:$bgǺ+A%»î#Õë®d\f®\9eç¦\r&\f\91\1eëº{\82Ñ\11\Â0SêõÓ.a\b¼\94zOÞ»\84ó>\9b\1aÌÁ\84\14,6\f\18üÅ¡ìÃ\ê\8c\1d\80\8f\ 2ø\f¬ê³ë[êͽϢ\88Ë\18ðׯ0êRê­¢þÛW4·/*ròç´Ê\88kCÕw_Ð0ýT1\7f\7fë·5ÇÛ¤3<ì+i¿\96êËdÜá4ÆX\ eå\13\ 5­<È}\1aÙ\89õà;Ñ@H`Ýô\99\1d\ 1ªï¿\1eàO\8e`/\81Ù~cPüYÒï²}ö\16J6/´\90\i?\86äîÓ\83 \86äñìw(ùûç\19ü©\15\ 2\1cJ7ǧªÒ\9b\7f³\16Ïåb\8e\87W\8f¾£\9f\94Ûï\9f\92ª\ö¶ëõ\8fPü${óúÃv\1a\81C!\ 1Z%\\15Dã{KQqDÇë0À©\95FA\19Rt±Ä\17]$+\ 1\a\8d\8f\13Å8}\8bO£í¹Ó\e¸Ó\bè85g2æÖ\b×\9eÒL§j­tvÇpz\16\89~f/Æ4§\82\bÜö\9f\98¹\1aa=tÊvªëë¾í4K8ý^\8f¬Î¶Cä\14N\18Ð\18$À#Üiî!\8a9ý~\7fÕÆ\9cÎb±\88ã4uñ_ç\17Í© "\80\93W\8fÉå.WÒi®ßg;\r×þªL§jmT7o\88\9d\1e#\ 1\16çJwÊr:ñpª«y\9aS\80\18t»6þ6"\f\80Ï"¡aä¬Cwú#${ez\1dCNí\8d\fª
\99F\ 1 \9f¬BüÚÎ\Õ§\7fw\17ya~grßú2|w\19â°¸Þ\8eç"¶&aÎ{¢sG\ð¿rÜ\9cÉØòt\ e(Ê@jS¶]\9c2\8evljÅ>\80.\1d\94q\r\ 3\ 2Í/<¯R¾ÝÜ\8a-        \1dQ\99Ó\95\12z,%ÑOÇic\1d\84tµâ\r    L\18¯ Ö® \!Á~\8aÛØ%\19{oP\81J\89y\83\10Z×Oé¶b[fH\82HÇ©%I\f\9cZ¡à¥\ 3\vJ
+\1f\a'g¥ÛÕÇÎ+¸Ôá>ÇÄ$»\ 5.RÞ!¡Gàì§\vù\90üÐäßeø*­z\8có1X~'~|á\ 6\1d\9c)\7fxC\82¹x\ 4¥\1e\8b/êëMnÈ\bê®\83â1/\14ö¸êË\9fh\a\11V\87å¥Óñ\98ê\v:®úò\9aã\16S_Z'1A´\8e\9c=m]õ\9aÎ&ò\92ÇtÆ\10{\ 2z,3Ú\96\9a~7+|¬¸s\vFjé035bÂÀäØ©ñ(ýçD\f\98íU\\81\98ª\ f¡¼D\7f÷ËJoÆ\98"\1fÔ¼\92¦%\ 4¼PªåQ+½¿ô?©bæIe\97       NK¢P^'\82\1f0\ e,ä:\ 1\1aæËW\v4VúsÞà8\80\ 4\91jÌD~\97$8põ\14©Bj\0»PÕ³Ï9'Ì$ÜÛzÖ b_X\ 3ä\ f¸êW(å¬AÄâÕ¦o!àcu`\82A¾IÍ=A±\99\8c\ e?çìs"\ 3¹ltZdè\90d%y¥¾l:\8aò/\92\97Ñc#6Í&\1cĬ&¶Ê\98\1c¥\bB\9aé`2Nª\81ô\88 Ò\ehþÝ`\ e}'P'ZØ\f1ZuA\8f\r6\82è­H8ë«CDêÌ¥\ 6¹Ï=\gº¯xÛ-#2$\131"¨M±ÁZj¾j\9c\fÉ\9eöæ-F\ 4e\17\8fGQÎÏ£~K\e\94N\10ù*øyPýv¹\98`é­\8fc5\83þðIîý\83\8cu}.\1edʼøü\8d\91[å@Ä\86>\87O\80$Çë#"FN´\ 3\11{Ù°\8c]¹'-E\1dî\10+l
++\97\94zO>\81r©ÃMaëìJ?%Ì0Q\fq\18°îJ\96  ß«¬ÕÓÐãMkà¥Ô[E=\81\11í§m®·äÏi\95R¿zª¨5oh3\10íJR\rÐ¥XÝ­-Ù\a˾\ 1P\17\7f¸Ø\95¦ÊJ\80ÈXaÂkédß"\17\f-Yz¯ñ¬\16Ê"@\88ý­ó\9f\94,<=ç\86 rÂ\91\rrû¥\        A\rc\86\f\13*\9f\fx\ fR\97ô!C:u\85\ 4¸\8fi\13\14Ï~V¤zJ﫧÷koõ$¸%\ 1\8b\f×Péêü\99¶$É   \13Ï%32Vá\0\83\8b\ 1E\1cñ@ÌQ\ 3<Z`´\11½µ\062Põ½pb\r\r\ e\9c\8896Ú¤¤càTÙ\90\87\ 2\82HS\85\1e-à+'h!Á»r?(­:2t^¡ê\15\925\ f°»ò«8qhgAä\vÊODx\87dj\18+([=ïkg\13¢½±M^¹Ùèù\!¯Ü\ 6ºr­Næ¸s\99Wn6ú?ëÕ½\9f*\13D\9fÀ\87À\ 6\88Â\ 2\1a\95Ä\1e»&¦Ø\12\8dåÆ\9bâM4jÞÿ\9b]\90\16Q\8cß?û\93\ 5gvgæ\9c9£x½{§Ü\80ÊÉAµÝî\1e\11>jÖÈË.F<§\88\89õ \85\16t\18nIÁXö#\10®&Ò¶«\99\14¬A\v\a®&g:÷Í=W#KY=µÊì¸\92mGI~!7·\9aµø Së¬ÙÐ\8b#ö3[..dïáöÊ\19\aab\1d³AÂ:ê\ù\13mbí[\9cøéÊQ\81Ù\11\16µkÂ]ö\ 6Æ\84Ù\89wSv\88\8e\15³N\95ìÛ­\v\92]\ 3©ÒÚØ\ 4»\9ci\a¨½\ eTR0Ô¸\83d\aEé;µ\18ê\18ûódu/\ 1Ðø<aýº\8cCE,ëV\8a\92\17}9@ÂÊ\rsüÕÔ\1a3]Î.º÷V¨ÓA(k×\94MýÅ}\85BÎå£.¤aß~¡t¹¿Ü_\9c\a\81»¬£¿¢·OΰUJ¿\vÌ!²6zå~Õ\8b£\13w\11\1d'ô.­ÚrÌ2?õoï\8e´º\93\e\1d0Ìl2âNÅ]\ 1\8e\19ýr̤Æ0b¸-\86ñ¢N\16à¯\7fé`L9ÀY»FÝ\9d5\86\8d¥6'Ö\18D[\87Þïk\fÏ»8Úm\17\10\86¼\1c°³\9ewO¢\ 2l\ 5¼\1cÓô\9cO£#p\97\15|\17·v\14æáÐipakåª|\19¦¬<F\8cYGØc\8cÙ¤&\9a½Ï\18Ò÷,³\18ìòû\91ãvRæLJÈ¢`\8fVxØXÈ\ 5\99y¬½Ër\7fs(ï>]\85\92,Zk1I\b<%YE\ 4Ökø£[\8b\17Ø{¦'Å}bÙ29\15\aó\92\81w\93\82-\0\19d\9d¹È%âÛ»t\ 4ÉËñJ\ 2\8ce\98bÝm\0U\ 5Ëî1&Ö\e'b¶\ 3]ìx\ 5ÿ£ÐÖsÎ&'lV<®í\88¡ü{é\97§!l¹µS\1c®Ë'ßj\97\88ßÎbÇرÂÐ:åæ\19­|@\1d\e t\98,\b@l0¬\8ck\99mâ¯oôî\1av¡äq^@{ý\84\9d\0C\13\b\8b\83êj«\94~\ fÃ\8e\v9ï        ¸\84aç(\18Ú@\88yÌfìt\18ö\976\10þF\8dã\1e\1eÞ\ fC\9b\15|\17\a;§ÀÐd\ 5\83På±Óìì\80á\8e.vÐÎ\1e\18Z¤½£°ß2\f1\96\7fHÖ~iL\13ÐÚ?h\10þe\ eãáj\8bJ\82\9d\89·±¿\81ù,¤\11_:\94×àk\17\e\1eËc îÄãe\8eS\8d\89^W\93£\v\99\ 3¦¢\9eÀÉ£\vD{æßÏS\1e\17LÕ%¢ó\14¾\ 3¶Ôìt\16§òf\97\90Ë.+j\8d\1dcgð\v1egKlg´2Ûá\9a\92n'\8bf\9b¶ U\91ÞZ&ÞMÙ!aM\89¤\1d*Yg]#ñÂë\82K\ 1\ 2\8ba·0\ 44µÂ\ 6\f\89\17Øk«\aÖ9ù·0\1c­ö\88\92­\f°w1Î)%=|\97\8aCã1Ë\0¼<ÚB©ª\8bkË5§Ô~®±\19\ 3\7fýË]y\ 1S¯¾\ 3\11\vèË­z²PnZt06w\85J\9f\9b\88e\94\9bæÿ3W\8eVh6\19µ]\1as T\85ám}ÖêÅA\1a:\96\17¦Â¾\8b\8aÀ5vP\1a\82Åéú§0\84=\97ÂP\9b^\1d¥¡\94ï=\7f;¥ÖB\ 5FCÙÓ\91\v¼äØ\ 3,T\0Ë¡PN×V¥°K\8fÙ\8d\89\9fÎÆ\86ßùú!\11¤j\18ÍXtáhLö\9f×\e\87\8c¹Ò0\ 5>î¢kº`bÈä\88·\99\ 2æw4æ\80ÏþÞ\96·³9x\ 2{\ få²"\ e5\aU)ÑÒp=åíía¸~Ù8\1eY\ 5®êÀ,;\96f*\18³H»K:Yñ¿ëáxÄú©è\ 4ç¶i\ 2û   aÃU\1eðW²ò\98\1a\13ú±°=@à\9f\ 5öTÐÈ\8bFÌZ\8d±¦À¤c­\85\11OÛ$ê        ðÂ:VID¨àw±\9bïR°{·Ô>\1aÍ
+«UJʧÛÃ>C\ 5>ãQ\8aVP\89
+-în(I¹krçÿ\94<\97N­²\»þJ£âÕRF¥d1\8bJÃa\ 5\95Ãß·¨\11Ï?B^\1a\8f\ f\7fP3´æÑÝ9\1dCw£L\1eµß§Ï¨C\7f¾¢NCüB\9d\8fº\99é%\1a^Ïëh¸á{hT\8d|¢qè6\80Æ\17Oìju\15¡WëÜðlµ^\ 4««oeó¸ö-ó\7f\91ø\86\88¥nÏ^©ÐË¢\95>£©f;\1f\90âÌ\84\9eµ|\9d\87û´ÿs%\94\82RttE\8fï\94\84÷¾ö'ÂÝ\97Ztúæbv\ 6\17¯}à`¼Ò\95Ù \18\897\82ï\90\12®´ö\96ª\11jõ6\14\ 2×oÍ[RÉ\8d]\84¤é#r\ 6öí_\92âþEoàdIÿö\93Æzµ\8a²}îâ"¢ì\f\16   \ 6\\17Ô8\1a7\99\eÇ»\12/Üù\9f\eeÒ¨tß-¡²oÑZ­\13Ýç5í_,\91\90ê}c\7f÷\J\88tñA¼äo¨X|\17VëÁâ\1c²\ f»>\9bdWQbÀ'\9dZ\9aÔ¡*'Ô^)5\92&ZÛ\15\87а\ 4y¡Â¯ï=*Üy*Ráf·G1\91\89\17*m^ÃË9\15ÉÉ-*"\ 4\9fpØÒTäóf@q\7fø$>\9cÁç´ªff\9bl\82ä*÷±h¬sõn÷\89»\f\aÀK\89©T«0\81~\fJ#ö±\ e\98îÇ°âðc\86     CÍû"êä\94\8e\rÖøQÐH8V¡õ_\f\97.}\83\97õ<\84\1faI-æ¸_\87ñc\18÷J²Qày¼Áë\7f\14¸b§WÁç\19È\99Î2_x\9b\b"\12ÒQF?è\10=3\8c²}¡\84\8c\17bñI¹Ø¾È\82\17ã\154¸FzûªÄ\9b^\f¿\9f²Û\17\rd¼0»/+,¾)kö\Îräcð\82£gö].E\8c°\12E\r{\r\v\1a\ 1ÍÄ8Ù\9füØÀc[¶CÀ+\9b¤f Uàð'aXâ\9fðX\8dèý\ 5K,\^°ÛàÉGà \aÊ¥u\8b0c\8b°<ãÇ\9ejVÎÜ\7fòjþX?Ï\92¡\10      ý*É$x)\88ç\9aÓþ5¯y\91ó        9q>{bÿ\16^ÏJ×ù\7f   _ÂT\92\98PUcöéuËü`ñVØeÏ\13ø½Å62,\9eµSJ!×\ e\9e\8f\v¯ñú2w\9fûì\124IùÇÐ\13T2©_öOï-{Þ VP^÷²^^cs~§\8d°\9e° @\93ÿ\80½[\1e\87(\fìuɪ¿&ÞN\84ü\82\90ß\85È/Ð\96ù\a¹\82ÁÞ\87Rº¨\92_Zj§/1\82\17Òs\900oó`¢,BÖ\124y\ 1¶s\8cúkâ/¤´ÓÌ'\92~\9a)\98og<\81í«\97h©(51t\1fbÚ]zÈgê´\18ÝFc\ 5ÛPK[\9aQöÓ\f0\f&\1a;Í°W\ f\fð
+\r4ó­´0×T¨0\9b¹ßA3:E7\83*ͨ\15\9fê3¤\ 2Éu±\1e\83ºÜ"þn©}4ù\ 2^\89õaÐhE\19$l\18Ì\f£Íöº\98\6é/4{\9f\91\ 5º\r~ ¿ô\17y\84¥¿    \83±6K\rµìc\86       \939\97$Gxëm\b\18\82Â[Xá\bE\83À,Ö~\94\1c~\91é\ÕÕ\82Ô\17ü¢\r\80èt\9c53\8c\86Õt\8aÛ\1e¹\1e&,\87g\10|\97:\10e¼S)\8cç¹g\92U\83uPlZÇJ¢.\12\12V)¸\9cÿ:\83ä¼\\93Éâ*¤ß\90\ 5W\83\9c\86\88r!¬îM¼UhVå*¯æÜ]E\\18\15aÒü\92.éªÒèY&Si\fÍæJ\ 2ÕZ%òï\82q\ 6\9b´5D\92\1a_áhGÐlª\9cÁ\92J\13¼$k¸&¢ØK\94ÈJ2ØêK\10/^\18Þ
+Yi,=\9d  o­\9ehU\94\9ax3\953\9b¸\90\ 3Ï´$\a\ 1\98\1e°³\bÄ%öávDº\1c9\14\f\9fÏ\97v\86Á\8fbYl\17¥ËÊR\80\16Õ\80Qaä¯ì\9e\82\ f\aÖcÐFS\Fb\13r.äÏÀ\88ûNú~[;Yª\7f§õJcV!\8f¾\8b\90: 4\a_\8aÄÆ#UG\7f$ûªÇ¡8}ºN\83¿p\\1aU^RGøËð\12óò\98\15ËK<O\94ÛeÌ \7f\8düy\ 2»2(\a¯nn°è\96ÄòË{\9adÐuþ*Y¨\9c"U©B©\b!\0\4     Ùgo\1aOûËF\ e\8aV6\9bëó£\9câ\8fã\9e\80\9cO²]àñDDxëß\96áðÑÇ\83NÏê䦨6íe\8õ\98ïúç6\ 4c_9Ê@X\87WðïRîp\ 1\räÜ8ó\1fíUÚ\90,\17D\7f\81?\ 2\13P\ 1Ù4·\Á5SsÉ-3Mëi³rùÿïÜ\v\bú\18/\85Ï\173ѹwÎ\9c93\aÌ\9cDÉ@\ 6ÿù±rzÈï\bÄÁoÄ\84¤fÞ\81µµyJº'ä\12Pü¥øýR\r\19\92R\8bÁEÒ""{\12w´î\92´\9e\82\fÙ5|\89"\8d\97\0\ 5»Ç\8a\12\1f¸§\82Xº{\97à¶-\ 5\81\95ÿÿL'"«4\12Ha$6ñSêæC\90i4'©oÝ(\94³_\91)uzÿm9Ñ|Á\ 5\ræ«\98E"\9b\98g\7fF]öé=-²\13ß%\93ÞR<а\92\84iй:ô\95zÖ¦gÝemüËÀH\b·[Vë"­³¦ù ¨ÈGÑ¢hø3¯\92óÂÏZ\e\ f\89¾~\ 3_\7f¼Ø\ f\11°\86`\9f\v\a!\18Å\97)à{ac*ùã\ 3ÙÄ        \7fæõ¦3%aN.UtJê#h-\1exV0lEÒ\f!,¼\11þ D¿ßÌi! À³_·=H§ñð\87±ä×&`á6  \e¬L%G"Ì)\95\ 5\ 2á±|ÅãÏÀYÜ\84´ÏÆë\89\8c\9d\851D'\9b½ÙuFkù]HO×;k66]\19Ô%ùи\12øÆÂ\8b\1evºûÁþ4\98í\ 5§Àxoaµ½OÁ\ e\1a¹Zâ\a\ 1\7ff4\86k\86\0\95Ó¸\9cz]¶\ 4:\96Ðj\10^\8f`­.N\bth_ó\83\9a¹|ëÖ-ÅI\ fØ¥\8eX>p\89{\rC9\ ey_º\80\13S\84CCh\13j~\80¯4îóf"\8fVHF\aA]·w Ü\9a 0Éí¨±\83 ¿\ f\ 1c\81\92g\1eÒ\0!!Z@P\86ó;\ 3\ 4¸\8f\15\ 4´ü\0\bv\10\ 4}\16\b\17äb\1dÛ~u¥\81 \1fª\81 \97d\1f\84c\10ÀzýÊk\87ÊÑÆ«\ e\81´\15\ 11\v\b6<àMb÷\89\ f¾ A°Ê\ fF&\ 4þ\99¯u{\8c\ax\83\rø-8\92\17Äý1*}\e\ 2\ 5\bØ\aЫo\e"èö\ e\8c\87\11\ 1ÖÁ\1d<¤í-8·i\84p\0\1d±ß¥Á;½\ 3ôË7!\ 47¤B\ 1D3\80\87üU\b6pÐÝö½\r:öWw³Á\1f\858\12À½Â°ì7w°a\ 4Ú.¬!8\a!öîp\beèX9\91òïUCÎ^ûýz\88i¦±\1fÂ1©\ eî\0Û¸\11BpÙ\e¬ø-\ e¸÷\1dô\ 6+\19!ÎÏÌæZ{K\97ÊÞ÷ø ù=ßRN6uÄ`\93x\97ö¿yH\91c\ 4±Ë\8a?T\1d\93cN\81á¿#\88\rI\ f\1f¥È\ fÚ\95?J\10Ü\95\8eÓ\10~Ù®&ÇxÑm\1aÒ·wØã\98MÇóòÿß¡\1cN])\8c\16`\95\8eÈ\a\13YrB*»;H¬ý\1d´ùòý-P\88_\90j?@ho"ÿ¦ã%'Ë\rlã6Â%¹U\1dI<à\98´/\0\92¬\9b\ 5ÿ¼#Ì©ì\1am\87yaN\8f\94\ 3#\85ÓPÏ\16Õ6\19®«×\12\9döªº¯4l\81y\8aå7_ð®ý\89\1f g¡¡,ðÓ/vç\1cá<*ú\89Þ}î\9eÆ´\r\15\9ca]ßUõ\8d\11ÔÒ´WhËôak#å\aLÁbNÒ¥qP¨\96Ä8ZÓ\ 5ÝÂF\ 6+aÑ\fÁv¼ñ\vx\7f\87\93\ 2?h\84ð\rå|L\8e\9dwS     ÅCæºTr\99M
+7>\9c\ 1Î?ò6\9bSê°8ôï\99Kÿ»f.µSÒ\ 5Òòbu§\1dAKC\bøb\82È\9f­=ä\ 5ÓM®ÎÓÝp=\17\1dÏý\18\ e)0l\13\85\87ׯ8Ül$åÞ?jëÜe¯w/gn>óÊó\94\17\ 5~Vcw\ f¦z\1a³V\beÏÂê®\ 6´wSï\r\87»²©ìá-.­>ÀÀÖ\r²p\8a\81-\92ã²f9¥@&\9bDa\93r¦³ÉG6Mߢ4\1eÎ^òo±³\98À÷_ÏÀ1¬§\ 4;\99w\bv\1a        Y.\92.nß0\17µÈÕ\bIÂ)è\ f~Ñ,®Æ\98AW8¨ ªß½ò'zù\99ëä\96=p-µ¸\94\1f\ 5ï\8a\93ÀèR
+<ô\9f³É\1a±Bu      3*Kn\8bþr¥"©\99è\83\874\1eõ8-\rõZAíÜã\8d\84{\90úl\1cØ\81z\8d\ e\880é&M\87×a¶¥\ 1½\98NÂz.3éC\f*£!:~\88\19¡+\8c΢i+oº[­\19\90!3Úë>ƤÏ\9b\ 3ÌE\Ú]o`dQ\85ÊP\9c&õnö_:^z\99zH© _\94\99\8c\14\90$\95»»\10\1e\13\86\1d
+\ 6\92\12    í\aC\½ùÚ;ù\ 6×\8aûû\81*        |$\ 1þ\85¿joÂÒd\1e¯`[(Ñ©[N
+øî.¤|\7fÀ¡\ 3òü\9f\85ê\15\16¯\89´ðØý¬ê]2èq\88O)Ô*\8a\94\1fÊe³\92Éñû¤jj\rl\17\85Û4£\95\84ÎÔÒ¸\19´¦Ùÿaô\85\8f\1fZzã¥ÂÅ}S\1a¯\97¼~Ãa¼\8aò»a2\81\18\ 5\9aLn+\82~\1f\83ýFÖWKþ\99\84jãö\1cj¾¾2\15\14\9d§ 
+\14uVnü\ 3\14ñB&ç´$SA®\0¿­(\90ÄM\1c\9eëE9Ï?Ôqqä\PVõâøç·(XE¦z÷\97\0åkDx\14k)\99ºÈD¤ûúc\8b\7f\1e´²è\ e\82°ØLsÀÚ\17EO#\12¢MJé\9a\f½ÚX        \82?Äë<I}\92ÚåqcÏ)d\16\80;r¦Klq\bM2\10\ 4Z\aΩð\87A\1aèíÂM¿\8c¤ç\16èÃÓ¸÷\95´LÉeЬH4(\96ÄF
+ªªp\ 2\9f\ eûwÁZ»ÞøÔaC\11\8f<ø[\9djk´ó#© Å Epíô'ÁŸ;\82ýóÒ'\98\87P\8c{\9emH\9eóÍß\v½ü ®\8c«gå,¿É\æÊ\11ø\99ß7,\13>56#Èeô\9dàrò\90àxºN\ 4\9f>\9a"µz 2ñóÂ\1d(\7fù¼\8e~Xo»ólº;îßizh\båõ¡dîî¸Z\85ÕgD¥(z\10\81Jg?t~öG+S(PïϾ¶N\87Þ/\85\19+\8ceè1"«\90\8c°xY \7fÚ  \1d\8c#<\8c\12OKº[¼(\84?ðy\ 4ýÙ¥\10Æ\1d89¶Ù]\89ÆÚ\ 5
+Ó¿Æó\85Ú{\99öÕ]®q£\7f±^\ 4ª±ëx¬TÌÒ\8b\8eZ\99§\bCÀûb± ]Åн$\8b\1c\a¶óW,Æ8\97\1ekUêr
+M\9a^H\97èaEDÍî\93Ô\87F\ 4½\93µÁ«\1d\10nû÷V\1f]#õ\7f'\veM\8ci\15Ô\92Nµ¾,Õ@±\81ý\12\a\117\11\91­1,ÔrÂ"Ð9c\1aÜ®ùzñ\8bu\8a,äâ\10[7Èê.É\ 1¶n\90\85ê;Äö·È^µ¿ÐÜç#"\12\923\ 6\9aj\91?Ì:w­\8cÔË
\86SRep\ 4©\99\9a\1dU)ß\8eÍ+!©óc\9dFi\90û/-\1d1}\v»®¥þÞ\bO¹öÖ÷\\18Î\9bh9ï\88;)¼\97ÆÛ»¬¾\9e\r¦aËzV\9enâÆÞÖÐö1ØÍ\82¹è\12>èòz\7fÎú\828«U\ 2z}µ\9d±\ 4\e\105Pÿ_p\18<\9b\8d
+\90oz]PĸP\1dT8\84\95q¼þá;@}Ï.X7Û\1a:Ån_;Ͷ\ 6]i»¯ýz[+\11\949\ 6\8b¶q\195 ´ºÀDN\80àFS\18\88¯Þ\10Æ\18\96 \ 5Æ\98\180÷÷²þ7\1e\ 3ê²/>ÿÄc\18LF.ãßy\f¤ü\7fù7Fx¬\85C'\1ce\1eÒµà:\90[\8b³ø\87£ÌCº\16\\arë!]\v®\ 3¹\85}Ì­à:\90[è}·\82ë@n\11\93Ï2\94\eÁu ·\1e÷\82ë@nµ}Ì\95à:\90[m¾8\17\Ķ\ 3Áu ·Àd·\82ë@n=¤kÁu ·Àä\93x\87¿äö.+\98r\8b6¥Sx\a{¹EÛø)¼\83½ÜÂ)'ñ\ eörë!m\ 4·ã¥O³ßB¿¸\15\\ar\8bºÒ¥à:\90[Üûî\ 4×\81ÜzH×\82ë@na\8a¹\15\\arkñ/¿\15\\arë!w\82\eùw£Ìs"ï`\8f¬e\1fûé(kÒ´Sd\rµüÉ(\83ö\89\ 4~4Ê<äi¼\83ý(C^ì\14ÞÁ~\94A.'ñ\ eÇF\99ÈÒ\7füx\94á\1dæ\ 4ÞÁ~\94¡Ýò\14ÞÁ~\94¡\þ£½º÷\92ç¡ð\15p\11\8c\96UJ\aÈ\92"\94\r*â¢(¢¼àâS\90qÿßI:e´TÚ\7fúC\9b&'ON\9eáDv0\972|÷ͲÃEb\129:\95É®ï`\9bðGd=\84-\9bðGdáôíØ\ 4\13\93\91{M\82\87°e\13þh\12àVÚ±      \7f4      à\94\ 4\189ª8\98Ê\80Ç\8c\94rEÊ\8c\9e\94!\akÃ&üÑ$x\b[6A\932ÚV*ó\10z.sOÊd})¹,eØ\8d+¹Ì\r\99×»@\12±¥\13ÙÁ\9c\14\fÞò¨ì`N
+J\8f\1d\9d\1dÌI\ 1!vPv\b\1fC
\8a\1d\9f\1dÌI\ 1ù1'²\839)h*vdvÐý-nñ\r\10æ\ e×\19R\80s1u¸Î\90\82ÚÉû\1c®3¤\80\߶ÃE\1dÊØÊ\ eæÈj«\1c\99\1dÌ\91õ\10Îd\asdA_\8eÈ\ eÌk;A\1fàoÁ[:\92\1dÌý­\87p&;\98û[\85ù\8fÎ\ eæþ\16\92Åùõ\8fÛRæ±p¸ÎH\19b~3\87ë\8c\94a\861q¸Îø[\ faîp\9d\912¸/¦\ e×\19)C<fæpÿ&eÉ\rdA+\1dÉ\ eæÈ*\8a|tv0GV×\97ã²\839²ø\öd\87\1d\8fR&»¾ã³\83¹\94\81\87q$;\98K\19 vdv\88"\15\v\99K\99\87Àbæ²\94ÁÝGbæ²\94Á}Áçë®\94áN~\ÆÏ\a>Ò=)ó\18r\99{R¦û17¥LO\16\aK\19i_Ê\90\8a\1d\aÐ-d±c ÷\0ºE\9d|$á\1e\88-\9dÈ\ eæt\8bï\8b\ 3ÙÁ\9cnÕ,vlv0§[XÅ\94p\9dIex/6\13¯}d=\84ýÄk\1fYÙ)ÙK¼»¥ìe\18Ü+e\1eBÏeîI\99\87Ðs\99{R&3?ï²\94é®\ fIÙõÊ\1d)3¨\98\8bR\86î\8b\9aËÜ\932ÅÁÚ\96\96\94y\b\83¹\94a}q ;\98K\19î1\a²Ã>)ã1²h\15»\89×>²°\8aíÄk\1fYp\17\13¯}dá¾Ø± \7f\942Ýõ¹)e bvlÂ\1f¥\f9%\e6ÁBÊ^Û       z\97\94Á*Ú®Ý\932t_4ZwMÊP'«¹Ì=)\93]_Ì(e7)Úi)ÛT1w¤Löc/.K\19êd5\97Ù\95²ÂÁ©L^å(Â=\80n\ 1±c    ÷\0º\95µò(µ¤Û¯\15\ 5\ 3¶Ñ³\8a\8a9mÀ6zVÍb\av-\8c\eU\14!\0 õ½ \ 6¥\94å{\8c_c\10\1e÷\10ì\ 5¶y¡\12Ä\1c\8e)Au\99x^º6È\b×ñIzÇ\v\99zàSE\96£\0r:\88j%µ\ 3\ 3\9e
+'O¸rì\93áÉH¬\84îþ\8cH\81êt\87J\ 1½il{²»4º4÷Æ\95\9fg58«ÞrëE¤U\84\8eð\85\99É4+0¯·ó&ö\96u**H÷1$\1ey\95Öo;@\8a\v\ 2\0\14\ 5\9eäë\19|AØ\1a{\99\87qbL\98\87Æ\92\86\ 3>É®<\95º¡\bÔÐÑÜE°Ð\16ðAÉ-Pêóuýz¥>\83u\ 1MVBÍâÓË\8b
+\9dE\1ap8«1\93å4\16ÿ\10òY¦\15"ú¸ã¡Ì'       \86L×Ð|µ\14v}Ã\ 5O\96_r°ö4\11-pq\1f\9f¥àÅû\9ay\rþPÚÿ\92Ü`EÀåZS~ôE\16N#\f\f#MW,õ\96ga\\8ed^³¡$4Ã(\r\7f\12+\9eÌ=dp\8f\9dÁdOg\1cÜ\17q\8eÿ\vÿË©\93-"\ 5ø3}\ 2\8b\80k^*\ 6AQ\11\83Á~\9e`©ìå©.K0_\1a _õ\18\ f¡\19\ 1\ fU¬j
+¶Õ!\19ÿð'J\9b\1fÂÑfU¢8ÿ\8e\9f§')>\90\15[\86ÏÞglD\9f\19!æç\ 3Û\83\12\85\8d¹Yj\18Hn\94ÄU¸7ñ÷z\87íå\90\ f[åHú÷g[eþ\86ÀCÈ\85Æ\b¦j\94£ê\90a£Ój\ 5JéÒ¿gÜ\rÿ\16\8a£$X-¶¡ù±£à\8f
+[ÈÎÅÂïõ@Ŷ\8f[\8c\18®W\85\ 3àßÛHê^\ e;n\1f_\8aǪæë±\94ø\95Ø85äÇÖ\ fÅ}\1f\9e\89mzuýmòè\90³­_ê\ 3u²ù×ÆÇL#ýSt!\eÜpÌ\8b\982\80\8e\ 6M\9e<-$yÒ\e,Å?jOmäú\92ÀIí\1cÚKáS\ 4öÊ4\19&D÷\8d\9cí-\Å?¨\86\bHH\1c°×¸\bðWsÀ\1ca\16Ôç¡\0lòÉ#Þ¼Ñ\95F¥ò\ eÜËb\92\92\99¼\f\7f»U\94d.'ÀÓÉáJ\ eHÈ=\19Â\ 2\ 5G{¹@u!cQ\ f*Ú¤\1a\a¨K\88áq|áֻƺ\8fE\be\10\95³7JÙ.$ñcUÈJøÑ\v\91õe³\140w#V/eG!´e!@ÁZ!²îo\97\82ø×¢ÚÚõ·å\90»\19\1e\82÷²wУ%0 M\96CFKt.\16\83&+Ë!ÿyÍ\87 ½tî,·Þ\91f\96C\1eç{\87\80\83U\ 6\r-Ñé\8c,ÑéL\96»\86\18ô\ 5\rz·D\a\19\ 6«!³M\0q\8fm\fZø¬æ\91\1e-\ 1\94\86sëN\96F\96\0J\13K\0¥÷¥u'\83\ 3²\9cçÛ\12@iáµîdim      `ßï·îäÑh\7f\ f\8c&\96\0\8eÞ÷\ 3¨uòhº³\aÑ ¹ê\9d{"\18\10ö{Ï#1Ûþ¥<\01\93\ f·\1el¤ôYÅ~\9a\99|N¾*ÿ¦?\19àÒD8~~½J\80¨e\1a\10ñ¦q`þf\94\v\a\9eN¹RO¢\r\9d,\87]9öÊ\92\bb¼û\ 5
+M*;s2\18ùîÉ»7\96\8eµ½>±èCù$¥\9b\\15±\1dßÐ|;\13P^ÔDJf~\9cOe\rPÒVÄP\ 3z«0ÿK·¤j@³\80;¹<Uþ1\9c\88Kï X\ 6)ïþ\18L7V\901ÉÅ ^¬\92HÏ)@b\88\83$ÖZ$Ìò¸\8c\9fß°(\9a±!ô"
+°MJ8f¡UNÂÍôU&]«\16¯Ä\87r«á½\86UòõÅBÈ\8fÊ\85èõMY¬?\ ete\87õ¨\10BBD\99\86øýèâ­ÉQ(|ÕÎã\få!P\8a*%W\9dÀ¤6è§ß\8a×ëÀG¥?î00ã\r«\ 4Òûûgn°~:Sb¯ô\92(~ÍÚKôâ\ 5ÐYe\94\17£Ë\18Ú\ 6\ 5"\9a\ 2¢\1fÝÆ!ÌÑ$º\95£\1e\ 3\8e¤\11F\ 5\ÉG\8bZ×h\9bµ\ 3Sþl/\17\8bDùCO´ê\19\10ÿ¡³
+¡ù #J\8d\18Â=æÁÛ\f\80пã*hEÅ?'a´\17Ú\90JÙ¸\7fy\1a½Í-²oßÁÛêi%1\93;+8¿%½Ôûç\rôKz¥Õ\15Ô®Ù\15îdò×ã¥WVvŵ3\Pð\95ñ   \1aÎï,8¹)7Æy¯ÒhR\8f­V¸ó4ª\8b\8b\96)b]\rÕ\e\r\1eOÏrmï\ 2÷Ø=exU®ç\91\97\95û\rVÞnùße\12ýâ\95û¢trøW'\83\1d2ú­æ\17^\1eVÑz\ 2\ eâúì\97?Äý\ 4\87\ 3wQ\84k?.cøÁ­òéì¸_\90´\8e¿7"Û\bæ\90q
+ëw\ 4!\ 6\17\88{¾x¾@\85Æ\98É({\ 2\8f¼\80]­Ü\92Á|o¹9\19÷<«Á\10¾®¯\9c+uïα\8dÛxá!2ui-\82\r,\86¡éD\81'ù:¢¦<ÅÖØË<Ó¬\891Åó\v\15\14BO!âtÚ\15\14\860\94¡ø\87\90Ï2­\10ÑÇݦâ\80OR\92§\ 2\86Qz\90\ 6\91ÍK!x\7f=W.C\8fño\7f\98Ü»(\auU\8bÌë0\96Ò+D^½\aç\ 2\97¸     {y\84)jÞÊ..ÚN?o\97ø¬\98qðAÄT¯\9eþã\12Z÷ó\85\eþ\9bç!\e\90)\9e\18\90øjOt\82'?\9e\e,õ6or\83U(Å4á\\98f§*âÉøÂÝEËpt­\ ÂÖSL\1dbHZà\8b\91Ì\ 5\17\1e\17R<\19\89\88\10]ÄS.Üï\ eõ\96Cw?z®ò¸¹\1aV×ÿíÎ\13Ƹ¦\a©$3\ eu¥ê0üÐBùe9\rBbÊ
+\90\83æMô5tºt\1f\ 3XÙ<üÙ
\93\1d¬CF÷¯1?\1d_&\ 1\ 2ÿY+\9a\1aÅÿ\r\1e_Ëý*W+R³Ï¡7*LsÞ\18é\1dx)®ÚõFÿÑi\9a ¾Fq«ì\12\94\r\10\8a ÈDrA©I¦\9dU~iäùútVÐê.q%)ZÙ¸Â\e« Ò\7fp!²ë£4Z \95\19Ùv\16\10KåeqDìÍħ>\1as\r\84F\99.\ 2íECÎ\91.iý\ 6\9eÜæ³bñ\96Ì}\9få\98»\80²
+\ 6+ùßhL\ 2DýЯ¢PÂħ\8aÕ\10_\10í¡;\0àHf\17w\9f\b·\89\8bbj0\ eÉn\1c\7fíU\1c\89ôÀi\12õ\fM</©\12Õ¦\fÚ%ocÔ¥eÙª<\96Ãò¯\17ß]L·\ 6xzÅ)\19\1av¯ÏÀ\14­\9d\ 6nvØä \82z1\ 3\18Õ\ 1H\8bÿÙ/ϵä¹%\f\1f\ 1\a\81\18 \90@
+\bD\8aôª"\82\14\15\ 4ÑWÅ\82\80ç¿gÖJ#"Ä/øoÿÉ¥\17IfeÊý<£æxå\ f¢\14\v$\8a­Ü:ɬ\8b±\9b['\99%ºo+·N2\8bS¹3·¨I>'^\0µò»\eØ·\17\80(\eÜ\80S/àß̱½9Ø\bÿ\7f\aûG\ eÖ\93ÄZUü´Òlæä\98|õÚ7O^r¯qO\1c£x\16\vi9vs£iÛÍ\8d£!Ó\91P]\895@­Ä±¨E\19Ƹ\18z\aÙé\b\eÐs\97\7f\8aÕçÙvö½K»;w\1d\18\12õ\95ØûÞ³Ö©í\béT\17£öj&v¯71¯6ìE\1eå½\eÖº¨\vµ\9aܲz}ÉøDÑúxá¯åé\8fRF:ùrþߤ\8c'Ýf\ 3·j\94?\962\17ã\18¸6p«j%Ü\1e\9bÿ\9d\94\81·ä\84wvßË\97\ 5·®¿Y¾,¸u1\8e\81k\ 3·Øcv\81{ùÉl\ 2®\rܺ\18ÇÀµ\81[èd§Àµ\81[ºY8\ 2î\ 6Ü\86\ 5§ä\14¸6p«î\95N\80k\ 3·Ä)9\ 3®\rÜ\12Zn\ 6.\fáýø[¬þ>v\87í¸Ew±\8fÝa»¿\85\8c9\ 5®\rܺ\18ÇÀµ\81[Ð}§Àµ\81[m\7fq\0\\e¸%\9dL\1cn,ô\1f\81k\ 3·.çÀµ\81[\17ã\18¸6p«rì\17À­}ü>³ b{Ù\1d¶g\16ª¿\97Ýa{fM{å¾¥ÌkH\19x\98½ì\ eÛ¥\f\99¼\8fÝa»\94\91©ÜÃî°]Êà[¶í\ e\ 4ú>ÇR\86\ ev\1f»Ãv)SýØ\1fK\19uJ\8ew\a«\ 1³ô¬\8bù\13\ 3\1fdì/\f\98¥gqö-]Ûôù"Ë\b×¢©~\18\8f"ê·L¤\ f1\90¿\1e\81Á\10µ±Ç­\9cÖâ\91O|v\ e¿ÖÞÒ\89Êá\v\99\17\82ÔfßÔó\0Ê3=·X¡
+\14g\16\9f\eS\ 2\ eàm$±or9\98\91ÂGbp¦Ä\85GåE¦¹ÃW\ 1ê¢!ò*\93O¾ CCbk\91¯H­øï?\14$À¿\12\84\9df\15\91FÓÄ\19P¾ÉÁå\86\97ØÃa\12\14¹Ïc\80\1c\8eÞ\ 1ÌËÃLI\v\8f\9dyM\9d\92~\97Ç~Já¨ä¥Ü@®\18µ<¾}\eÕ4\97\ 2\1dø8<\11T:÷fcZ&Ú\ 2ãÏ®1\\10ElñIÚ;Ø,úñªò¡\12I\85\9f'oU©È\8ecáçtJ\11ê~f@Ò\ 1\19\eÞB\11g_0%å\18\94\90î
+/)Hj\\ e¦¿¢^9Ó\89$á/       t_öJ\1dhªÞg\1c\13\8d\ 6'aÂ\83ôÜ?íë\93u¡þU\1ayÃÏ\,)ÔÎo\8e\9d¾\87\93(\8c\99X5Ý÷\ 4ÝB\86\94Ö\ 5:Ë#\1f\91\92\\7f0f\18'\18û8\ 3õ\9d\8aútÓÇäì]±øí>ñ@1^\ 5\1eæ4þ XOñìQÒ\96\aE\9e\11JfOAïKå­\ 1êÊ\9b¼~\10\ fªX¥\94\82\87¤þà)\99\1c\95¥¥¯wý2_ÿ׸|¨|\95\1aIì±\9aĶ2à`¡ýf1±\9c/\1dË^¹R\83âÄ\15\90ÛNQ,ÿ\8b\1cÁe\99\859\7fÁnKÔ\ 4Á\1f\1aÀ-Ñ\84ÌL}\92ìMf\8aP¦jNö²çq©è>Ê
+õÂa\ 3:GTÄû£·\82Pk\96\800¤aM#®\rä\114\90÷\rúÄý\ 5³\11ò©ü5\99óæ\aÎ\9dH\1d,¼`Ýý\ 6¡»Ï\1f8¸o´"úâñ\11×`bvºÏ½\ 3\7fÏ\17xø°:û©9c\b&Ò9´õ Aã H\98\8dGI­\8c£l<HFi®¶\1f\ 4_ê#·À·ü|ÓË\83\7f×{\963vÇ-\8f¾Ï\80\8bÙu\93x\10Üu\8bâç¶ß\ 2ßò\98\ fñ»ÞÓ\88\846ßb¯Ï±.ß:=*Lý­>Q1Ì\89Ï\fÔh%`\ 2j:Z÷\eñ¨ª`u)þéûà\a\17cýiÃ.F\1cPq1Ì\8f\99ÈYáÂ`²¦\ 6[<\9aê\94Äò0Äë¸æÖ\1cIln\9cÁ´âi#%Y=öO\1eE\9d\97Ý.%\b\19SÂØw,:\80Ð&g¦ü{÷uJÉbä\83Äsûæ\1d¯\9b{zi»\18\88\1d_­Ítù\15Ä£w\ 1á½\8cù2î\15t\7f\90ÐÒ¶¶ \9dø\1eÚ\85ê4åÖÜLO,\15¥Ó8Ñý¶dò&ì×t¦{\13ÎlZ*)´]Ý\90êW\ 6U\91î\13\85ûó(þ%SÇA\ 3Àòa\94\98dL-\99ZÁÑC~é¾õ\15\0£­OS5\b#¦^     w\95UTä\1aA\ eÄoÄaÊy-Ç7ËMÎ\1a´ò×Þú÷Î\1a   ó[oý{gM{ì'o\1dù0w2PWû\16q.\84SýW\12Þä\18­&\ 1ºIÛ+Q_Ä@nZ0\f\912\1ddúz]ºæ®­ú\8e\91µ,<Íù̯\95Ø8X¿\98\ f´ð¨\ 6Æ\82\89A\1eZ#}ãÛèëÐð­\a\90î>Ê\10¹·üöC \9eEª²*\89®\ 2\r$\11g\90\88t2\19\90N\13Úk\ 1\99O£6'\88=\13Ëây
+îÌóÔ8­YÛ\16}\99öA,1ÆX\81 >\0=L%l|ë\ f\96~\ eú¨´NäìââÜj?}\99@Yö\16ÆÇ°#ο6Ù8ÌØ7kdq.V[\82t>\81#§E\8c\9cÖL  \9b\90F\154-÷½c\91Ëw\14Ã\94\1c¬\15O.\e¶Däü\r\ 5.Ã:Là\8ax\9d4±%¿2%¸¿ì´%\98\846¾'\8fÛMIklÑO \85Å\81\92x\92\90\91f£(ró¼\80:\1cÒ\9d5\aäç|Oì&éùQ\93´\ 1Q\95Ô\0ÓbqâKgïÏâO\86´\90õ       |òºþ|\83\19\19§©tCQÿÒv1\98îYI/\9d²a4%êÆu9j,\17\8b\19g(HfH;\ 3óJ0\v¦³
+-Þ¯ò84<eòíò    ¹á      aÚ0ï\15?Å6\9b99&Ý\v´\84þÍEWÍÃ\87òí`ò\92{\8d\ 6æY,¤åØÍ\8d¦m77\8e\86L\92\b}÷J7\1e¢q8WÆÅÐu _GØÈä»üS¬>϶³ï]*V¹ëÀ\90ø\fìÐgMxÚ\11³ðdb÷º"ñªú\äÑëtÃ\ 4Ûdö» Á\93[V\a¥Ê¾tÙíýVäïþ\81î»Z\r¼¤V\0\9c\86\ 2\83\eK\91¼ã^I\94}v\10"Y\86ù}[\916%¨\80Ò>ä¬Â\9b½È_\17êU÷%`-UY,Ò©I!\13¼l\17ò\95\9b[ã \bT?\19\0Ø\92àÝ\96KËÀ¿Ä^4R:\7fôúÅÿe/¿\ e\9f\8b\83iSÀ\ 4\8aÁâU¯B\84Gºý\1a\9e¨ÂÓ\1fG\88ð¸\18*=\95ñ*¡iÒ9O5'\90\8dÁv0é\84ÕÏ\9dô\ 4ì1VMªÞÉ\81ì¤hr\8cú· \1dâHx\8cÒ\13<º%\90­\8e+]n¾ÑùDà®\89C³oªË\1as\8bªÉ\85g×æ\85.gGË\f¡ \9có^\94t\\913&\b\9f\80}rÅP»ã\ëêl=À\ 5\89\8c\9c
+\19?Ðy©cì Á"éN\1aJèå\ 5\83Et@p"§\97«\884\9a&ªÐ*ï\98Þ°_b\ f\87\14Z5îù«\82\9e_ñ'L\e\18­Fo6¦# \99×5YnñÉÍA\151*Þ_×ÛÀ\83÷°\11\99\15\90?| \8dîK\ 2\15&Ýáj\858}\ f\9fÆ' xO¾Nâiµ¢F\14\8dÃK\89t¥|x\¬ÉÞ³J\15Û\95\17¹O\1eÜ\85X\89ñ\rhírT,wZ°Ø2|\ 3\83JpÐØ1|é\v!ÿ\8dµtÞ³dQ\13°h\f\ 4ì_\1a´\8b\89\80\ 4\86\80\11\91Ñ\99\f|&\7fíØ\97\82\ewV"j$\8bh°(Ì\b7µNîvo \1aa\9fIãÃÑXÀ0\16B8\1dñë/³¡>s}¬éªkh%B_ZÅa\13x®Ð\1dd\83Pü$\131ü!
+8:ù ÈÈõ®\17\ 6\12\91\96}Þ¯\9f"÷½ðÎ@I¸\81=f\ 2å*²I\84\1cK\90\8b±!B\8e%ÈÅØ\10\12¤z~\e¹u"A.Æ\86\b9\96 ºWî\10\12\ 4\84Ù-B;$(ã/rª³Nõ/Í8n\1eô\89é"ßbY]$\8e\90\ 3¸:á×ö oT*ð/\82ìuóUË\1e´}\vÒfÿw{Pg^³ìAÛ· ×\9eö úØÿ\ 4\18\0\8f\9eÅi\rendstream\rendobj\r24 0 obj\r<</Filter[/FlateDecode]/Length 9646>>stream\r
+H\89ì\97i_ª\\17Æ?\ 1\1fÂ\12PAÙ\80æ\b¦\80\9aZ9\96Ú1\87Ô²\8eejßÿY{\ 3jÃñF±wÏ\e\7f\1a´\875ü¯k¥ª\89¤\9cn¬r\9c\1aÉÿUãùf\ 5\15z\v\9a¢Ñ¸¢©2#\17âhrÿlÈ\8c\91-sjû6\88\8ayQá´`@\93Øt /õ/ç**ô}3uî\eµ¹ôÍP@\ 2wYµ¾åz¬\98oÞ«hÄ´uò·\88GóÏÉ~\14\r;¶41\90}Îá¿feoÒ(Ê\8cç¬$L\95¡\84\8aírJ,DQ\81KKLTÒ\83÷º8¼\9fÉð
\84i^KIþN­\a\8bõV°Ô¬#\19\1e\94Ã/\8b\92ïñÎ\10ó÷¡\bÜ¥¤=§¥þí¤*e[«\b,q\9dFÅJN#×@ãA/\1cNU\13\12\97}[^áog\9cZafrºéù@B$ÄÂý*Úúj,ìWy\13\ 3\99\88È©ÊÛ\v^ÀGÑ\úi%ã 4ð:\1a,ÁæÈß`     Ñ\973¤Ë\18ücÁÏ©§)F\98\86ÈÏ5\84&ì{H\98ªJ\ 2\95|4/òì\93ßZÊ\9f\9aã\13ÖÂË0_#a[ïòíQ5¼\94\96\97°\81þ\12N_÷!%½±¶X\9c³jæá*ö\ 4\ fêsëÁ \96µ¾õ\8bé/ÿ±ôtY\9d¢%V=ÑáÑ\15\ f7\9cÓ°v9a}\93½U\92<Ñøó\92³Î\80\9f~M<w)\99Aµ~\96\97\8bEX\9f"¡õÂÁ\ 2\14m\9f\82þ\8b\84pÝ'\ eË\17qÈùE\10    \83÷ ð4Ö½Rwù\14\84WNC$l8\80>\12\9f>Oâ\rHýf#«\8aw\9cïv\86ÏÙ¿±Ó\18Þåt±\90\96\ 3\8aöð½QÃÃ\ f"¡­C©¹\8f¿hÄÞAö+!\ 6\15#4½ù0Ãk¦®ÝDä\98r6&ÇÎ\9aJBË4\99d_{\8a\96æ\99Fæõ\16ß>\ e\11ËÞ\ 5îs=ÿ]Iò?´¦çɲg\ 1§m\849\9d§?r¾ÂÅ\85¤§£\ fö\83Û y\r½ª  ø'|äKø~·\88S\87\ 4ìÄ\96#ðÔÃPô·$Û\19\f    ËÈ;I2\ e\16¿Î\ 1Cr\85&b9\ 1\8d\eUHäÍ;\v/'!\12\e\9f­H\91âÿå(\1aR;ÎÂ\9b}(Ø3\7f1V\8dÇò¹LU»ÓK\17\9eºÄ*Ja±P\95¡\9eæê\r]+üén\ e\ 2}ÎûH\ 3àµéÏ\1fµõ­²\101\7fµ¬|Ï`ì1SÿðN\8dΨ\82p\0Eθi\152¥ÛÛ¾Ôý¸?צ\ 3A\84¼\fÂ\99Ù[y\89\1f\f ¦WqëÁð\9aÔ\v\ fý\19}\85Þ\17\86MÁºð°\85p\8dù­°®+9\90\19\1aëJ\8elî"\ eNò¼µ}\v\9dZ\15\11®Ë\9fi!AWª«4Gz\11    J»n\86\1fù½1$UNÚ\9b\9a\ 5ï³\1dY\89'p\ 1&µùíö\91\983\91{\89²2\13@\86ðôFG   å¬ÞÇ\8b\ 5¿/v\13ÃMs»½sÿ-\ f¹j-¿=\b\942P\11'~4~I¨hÒ\9c\17q_ñ\ 4ï\101\ 2øÏz°¥\ 6¸Aļx­À{ZÐ\84¾\1d      \92É\9a¹\98}!à]¤8#\95µn\85\16e!åÓ?~\15¡Í¦2=b54é¡Øç\9d[x\81"\94ë\8d\84\eÄ aÙPÎ"\f<\8fÑh\92\18\898ñ×°ßãµI~\ 2\80\11\13~3;^\8düY\9a\9byTH\84_\843D3DFP)1RQq5º\80z©H"\7f\88\88@^ðbrúæª\ 4Â\14/àJ\ fBlµØgíR¥\80çVÁY-|Ò®\ 2û\r\9e×c\9e\88\1a\ e\eK\bIÑöá-zAq^/\10ò\85\ 4s  \93Τ\ 2Ãõ\1a~åm«¦G¾Z\9bР      \8d\97/ìçÄ\a\8e+9Ròm\163Åú_r´õ\0\7fû\81I\85³i7ZäâgÕ¡ðÐ-ö3\85³I\85¢Ï'M\94M_)åh\86\9f\aÓj³Qç=ô\9fÀÌ\13\14Ø+\ f\7fÙÒ=Áq©áá:¾h\b±\13n/\ 1#òEî²KÀøGE]ß%+eÛ\9cA\16³ûÊ\11d1a\1ccv\1c\82\86¬ðPr¡\19 ì:ô\83´¼\9e\8d\97ìB\ 2\18ù;\1c\ 1ùõN®ãût(ßÌÊ4Ñ\rÕ ·>Ì4\997m ­Þ\17\85Óe\8ak&\17gj3|\95\89vG>óöþNÝCÑÆÃË{\1cNv'­áÚ\87Â\9egm¸\96ù-ê\9a×\18ÖB&p\8d?ºßü68¹   Z\9eÉæ=¼,¾\92\12\86®Üö\ 5¶"+µ³§\90\\8e{M]\g\83´\0\eÀ\15\1aÇLF¶V¶\17V\8cW>\ e\13\ 4m"kõ¾\83غ\89,f²³Øº\89,QdG±u\13YØå_±Å\ e\17 ñ<Æ0o\84~ºsâñ\95mæRFø\8dìçaçMÆÃ?=7`çØjã\9dIW\12Ê·ªp\0\86Þþ\18´ôµå\89Û\1eô\93\v9gÇ\rýb¤xl{Ö\12mgÝ\906V\v»\8b\8fÑËÚlñÛ.¬ \84ðßB\96\ 1ë\\88¦ÕÔ\1f®#ø\9blæ×V{ßOl#?¡÷·\90£ÔÞ±ÒÆ,DãÁ`ÄHØÆÂÈÁ\979\1e\84¾Çã \aí\18ÿY
+\97\8dppã½~r^\14}lïõ\93ó¢èc{¯\9f\9c\97©b[Þk3\16:\98\18\9cÎ\v8/ÖÄ@ï?18\9d\17(W\13\83Óy\ 1´ÒÅÄàt^°9¶\87\94Eþ?\8býÎ,6\ e\99®\ fk\0v\17\84\ 3¥\8c0Ù¹M8PÊÌ®tl\13\ e\942s~ql\13\ e\8c,¹Ëñ\rØ\97ÈRô¯\18°/\91µý\98[\ 3\86&åpè\9f&\81¢÷² \a\9a\ 4\8aÞË&\1ch\12(z/\9bp IÀ]¹±   Ý\13f·M8Ð$PûÙ\84\ 3M\ 2î\97=lÂ\81&\81p̹M°MB\9aÝKÊ(z/\9b\94\11}qn\13\ e\942RcÎmÂÞR\16\85ì»\ 5®\ 3Üâ\88¹\ 4®\ 3ÜbEv\fÜðÛ\81RFòò_À\15yöÉçf*Ûr}\87\ 2×\ 1na\17·Àu\80[Òûî\80»\8dÛúêGÜâ]\\ 2×\ 1n)Ú5p\1dà\96T²;à:À­©/_\80Ë\1c{*\83»\1cevØ\8d[\8a>Îì°\e·¤\92\ f\ 6îfvØ\8d[k\17׳ÃnÜ\82\83=Êì°\e·\14í\1a¸\ ep\8bkìyì
\ epK¹\a®\ 3ÜR´kà:À-®1§À=ÜßR´kà:À­5\8b¹\ 1®\ 3Üb&»\ 4îwÜ^οD\96ôþ\11f\87Ý\915çJ÷³ÃîÈÚäÿ])Ãyùyv8¦\94a\9f|\8cÙa·\94}òc¿&e\14í~vðÆ_\84ÝRFÑÇ\99\1dvK\19E\1fgvØ-eØ\8d\ eâë¯H\19®d\1034¹?G¿'eÔ\91f\87ÝR¶öc¿*e&Çö\98\1dº4»¿\94\81\8a\1devØ\8d[¨±£Ì\ e»q»5W\1eWÊp\ 6Ö5kïrd\ 3ö¥fÁ)ý\86\ 1ûR³Ø\8fýWÕ\9aü5\85\04\87]ß%\0?\8b3sûm\82ÔÏI\r©ñ\82÷Ùb2\10a\95ÇÄÓÄ@v¤o\90\9a\18uÒíuÍßnGö\82M¢ñ ÇowÉ \96\95\99T6'L\95¡$ò=VGã¡¢JÙN¼h¹qX¬µüº\98Ô\7fËÃKra³s2[»\ 1\ 5©0³/\ fâ\85ö\87\ 6\aÎø¡ä4UfúÝ$ô\95Â\8b\1aÜ\ 5 N\vZX'0?M1´R6D~®\91\84©ª$PÉGwHµÙ\91 \99lÇÉbv\ 5ò\88D\91ôì:M-è}(\82\ 4îÀ«u{åìÚiV\80\17\vÚ:\9e\\88\83¨µR\92\110ÊPµ¯\82ä÷Þ§HLpÅßpj{á\11ùGEäÒR\92A\93\84/\f\ 5\ÉRÄ+\19Òc
+xQ\ f\a\7f*\19ÉYJN7\15?\9a4\13"<Ðæ2\93¼\8bÃ\19\93\11ò\8aÌ,\ 2\19;\ 3þTfà\1e\ 6ÆÆ~¯O\r/\9fÊÀd|\1eeÃ>X1\ 6\87_µÐZiÈ\9b§ÿ£½:÷\12\a\82ø\13ä!\10\13ZB\1a\1c\10\9a\10ºx¢\88\82\rE°q
+*¼ÿÍlzD\8a\81/ù¡ÙìÎNù\17­K´öªô!©~%çþìQÜS\fò?zç\8f\92\83\90X7g_ûPåÝ{³·\89¬ãÃQBÞWÔÃ¥\9fíË\85»rÙ\8a\ 1:\19£\80ÎÛ\8f»Wº6{\9eÄò®à±AòÎà\13ßî§\f\93\97íý¨TVî=J\ 1x\ eÊ\8eûeÕïwáh¡b©U<yj\82\94J\ 4Á¢\aì­L\¿ìo\8b¯\152\8e\14-ï§Ë\rûÔv¦\ 5±\96à\9a°²\1a\83\17BAºó\95\9bÐ\8bl\12Dg"\rIx\ 5À        \ e¯±\95\1abõi\98\81±\1eÿ\91B§¾"v|\ 3\16Ki\99\1erM\99ñå\81+á¿å\1aÿRU3 \92NûN¤:Ñ\7f\1d\8f\10Mú3¢W\büÛ´\ e*aèÀãOA\bFym\83\vJ[R\132\16.ÄY\ 2\1a0 ¾9Lr4@D\94y\14rDk\82ëD\9d7îûNÞ\17§Ë\ 3A\974NN\97\87\ 2
+ ',\r\84[\1e\bQJÙÙ\8a\9cä\95Öly ¸màÇ%Äñ\95\by\ 6Wìó\18ø\b¯Z"îE\16\1c\8b\94 »j\1f5Ê­ZÒQx×\12¼\8bk\11hÙåû\88làyÅÅEVx\ fYKHÆ\16,JÍVdGdUzavìK@;\92%Pý\9f\17\1f²\13cOuÞ«Ìß\7fzL¬_x\97\ 5ï5ã\ 3NN\18\ 6O{Ä*
+£¯q@\18\8d\95\1cd~ÚÀCA]ô.8ô\13èÔ\ e\83V\f\1aD\99¢\842¬Ô÷W\8bô6±k%ÿ¨Ñ¦c\7fK'\86ʲë\95\ 5_|\90º´§\1aàVo£\9c®\8fî?X\87øIL­\18\16
+K\ 5\89©BK%\0\8açÂËíªË¬\ 2¿ì®ºÌ*òþ\ eìªË¬Ú¸r\9bv\153\8b\16\12Ê\1f¤¿;\9dÁkñ_Ò\9fD\9dåÿü\94¾î}l\7fxæcïãQ[ H- \92®TmïF\9c¦­\87Õ©0\95|¯#,¨à\9dú\9c8\9c\16Î
\17\9a£-^\85oÉäH¡\87î\8b¡ôÏbv¥\9fO<\98\16\80Ó-ê\89ª!Ì\ 5o\ø\ 2®>¸     \99i%ö\ 3dG+\100Gª\88(\1fÓï2\90\80UÔ«K<þÒr`\96B·ó\8b!'\1ao\ e\11Üê\91n$¥u\8aܲÎÜbãË\9a@\90"o× Åò \ e%F\86´\ 5ÿ\10\91\86/iO\91ê¢ÎÍN¾ËïsR+îû\8b\92\ 4$ªDø£ö,&õ\87©º¼\9f\1aó ;®9MÁf\90s9< \88"\7fÏ\ eWdJL¸B\9fãv\e7oý\86\8558³\11­$\81|3GFÁð/Î\ f\13¯\81Znñ¡Õ\7f¼T\96ÿ\1e.ÔüùP\92\91éy]У1z\1f2¦ß\1a\v\9bÈ\b\8dãë?\1aük¸\19\1c\9eáy*¶@EDZY°\87òL\11\aÍn\14\14\ eßÖU¸F/\ e´ÜLËLùð\98\14\a\Ò)Vߥá@e\96PÃÅ@¨¾¡\89ËÇá\91j\82s\1a\82\86;z\82@Ƨ\19èÚWU¿\ 6H\1aWS­dä!ÃF\16ª"L\826\81C&61Íl0R>ïÖ\10z®¡}ø\80ÍRññDØéør± ¹ÙbºYðâ;:5¿\0(fY_ä\9f\9c×Р _àì[BÕD\ eÛ7±Ò\v\966Al\ 1dþ`¢÷K÷êÓ>¸=.h\r®UxRv]\8f-"8Û@\1a10d°±¾
+¤ \91%C£Ããx/\8a\r   Ö$5âpôB\16\ 5\81\1e[MB\9e)Èp|KIÈ3\ 5\11\97´\8a\84<S\10\9c²\9a\84<S\10ôØj\12òLAP\97Õ$ä\99\82Ð\8b­$!ÈòÁü×\14\ 4Þ\87°\98\8d\84n Z\918B¡\ 4P\bc¡¡\9cG
+"S¹\90\84þ\ 2d¶XBB\9e)\88¢× ¡Í((/ÎE¹È|^X'kj\\85\1dÃU\99I_¥È\80 \11ôÌÙ0P®ÒgøçI¢dÊô#§Ç°¬BF#\91ªÚLBAr"br/¡ RC\14\12\85°¯(Ö\ e2Iø\9f\fìTU30û§}âm\9d¥\13ÅÈø (²\1f>       )¨
+1\ 4SHe1á±y«
+\8dVE#\f8Åj:£ª\7f\16ò\8bq5\98éxk\82\92Ìâ\ 6Á%Ä\1a\17\83\14])KGIlºP$çÏ0@\89Í2Ф*\b\8f\81\8f(ÿ\92Ë*Âa\90fÑM\86\96ÓÍ\82\17'\84\1f\9dÈß\1f©\9f\9f9u(_4SLeÒe§\85\87\93\92ò\8fþ\16ËR1wÀ\7f=e
+ìäµïcbõ\90o¿\94¼õE\1e¢5_$7ná¯\ 3_øéóÄå¡,u±\84dVz(È\9du\17\9c\92EÚRßÖºÐ\97ï&\80\12ãôÃæ»H\r\86\8cÄAëÎâ"Û\8c°0C}\16Ç\9e3ðçú\8b\11\1aø"\ 2Í0*ZS\19j$ORÉj¥p¢^\95\ eë¾6\9c\92­A\ 2³\83R>Ò>+©µë\e+$T!ARi\9c\17Úù8µn*\85N\9a0/ß\11=ùThÏ÷_Ê\97Ã\96\80\90*\9a*åNº\99ß\1eè´Õ»\8fÙh«v?K\19|vÌi|\15.$ÞáÏ\ eª\v\8dP\ 6]\ 1\80«\1eÒ\eÃÀM\b¹WZ­="öjÜÑÿpR\83¸_
+ƱΡ\86¹ÿà\88.\0QúL¢\0\ 2ó·?]¹õ\92Y¨Ë\9a¹õ\92Y\8a^7·^2KÑëæö\87Ìfè5ô\ 1EoѤþ¨\ f(z\8b&õG} ¹$C!T\ 1\9dLõ¿EUKÑD×Bª\aQK×n[ÕR\vuí¶U-tò\ 2]»mU«ó\8bK×þ¤j#È\8bà¶^G!¼stÑ\9d\95§÷@§\92)Ç&ä<_`Úa(ÚÇ>¿\9eÁÙÉ\99\83s«ÿ\80ã»'p<CÛ\1f÷Ý\92Ù/)\83§\1cÐs\10\18\9d\95êCðczwwE\8b\91Ï$[¯\86æñ٫¬½\89kY\94é\17\7f/ë¢6©¥\87ã8þ\92µêj\aÄÚF'»\1av[Tv\96\88ZpKü\8b7À]\ 3n)Ú3à®\ 1·È/\1e\ 1w\r¸%ÚòGÀÝ\16\95¡\17Û@&ü2³\98±\rdÂ/3\8b§l \13~¢2n9\95QôFf÷\97T\ 6\89Ùý%\95\ 1ZºÍî\ e¨\8c"­´\8fTF@?°\13*3Xl·TæÐc\eRYbº.\95\ 1\8e!\99mFe\8f·\aÂFT\ 6,\86d¶c*#³ß\15wLez'ï\88ÊÚ3\86À-q|[ð\ eËáVÓ\96Þ½Ãr¸\ 5\8awX\ e·pÊ*ÀÍ3kx\87åp«¹WïÞa9ÜRôv¼Ãr¸%=¶\ 5ï\80p\eÿ1³ÐckæÖKf)zÝÜzÉ,"ÿz¹õ\92YÄ1{n¹\9dP\99\83ÅvFeDÁê¾lw®\fïbø²\r]Ùë(¸.\95Á)¦/Û\1d\95éü²c*ú\0\92ÊnöH'oÃ;,§2\9b¶Ü!\95i\8cìÝ;,§2½.+©ìhê%³väß\9d+\ 3m¹±ãÝ<³\ 6#oâx7\17  \14½\91Lø%\95Á)\9bÈ\84_R\19¢å\ 6\97T\ 6=ö]&pð\18ó[¤2¼\8báËvGe\14mù²ÝQ\19E[¾lw®\8c¢-_¶;*£hË\97í\8eÊL®Ü)\95Q4\90\19\1dØ1\95\ 1w\r¸%zÌ\eà®\ 1·\84\ 4\¬Á\9a\ 2ÌÕ³d^¶/À\=KÐrû\ 2\fs£¡/!\ 2rJ-`Þ%\f\7f6Þ´¡±cHû\80tQ.UÛ\7f%¿ \17Ç\15Ä;U\f\17\87%\vP\95áe¾gvü\ 5Ù\19ê¢å¶\1eH\v£û~Ä>%÷§E\99 s*ÿ\92\1dHÂã¹P\15F\83lN*^¦\1aZC\ 6²Ý/k3m+énR\85%rÍîÅÒÅÓs`\90\16óæz\95ªõæ*@X!\ 4-§ædF®\ 1àƳ¬X\15\8f³\0p*§;\14\ 2åþ\fÿ´\9ae\91\9dª$\95Aþ%\97U\84à}I2vþad\82Ô²§mf \0+\90,\92\995ËÔÅ\16Pp\ 2ÿ\9aÃU1:§Ó\ 2´ø¤­à c\8fb'->\\1d¶ kßy)´\7f\9b!9Á\9e?\8fäzïs\91\8a\91¼\94f\84G%\18\832\95xø3¾/\95¥§\f\1d\8bäæ¬_*§ß2r¾\93\r      \8f\1dE\84\17êTfÒW)2/é8Y$3\9fá<ü\99ü\ 3\bÔz\ 3ýp_¶a\96\117,öË4F\93µ\90\ fvLBð³®`2\r\87\94Ϫ\88\96¤½*}H«?Vt\7fø(î)\ 6ù\1f½óGÉ\91\ 2<$Öm\9f=O"9×g"Ûy²\9d\87uñËÀö\8azè8/«~;O\19\8aÎ@¿}¶à<\12&¨>{ \83$¹¡ã<\95wî½'\17y®â¼_f­»H¥ùUÁùaV\1cÜvYcåÓñ\7fÚ«l-q` ?\ 1ï0A\ 2          Ù\0\15\90\82\82(
+¢(
+.\83\80lßw®Î³\9fªîÎ\ 2£Â\8cÇ\9b\90N\15Õݵý\7f\91
+¤\\ f\81\9e< ¿Æ§ô­pS\9c9\82\8d\aD\7fà\8fL)!DÀ\81D\1cw!\8c\19\b­!\1e\18wåqI/õ\14\80¨Öït8\17ó\9fA-\8e¢áìi¸¨\1d7\8a\1e¨ÊiÕ]Â'¾¼^>ÐÊ`EÞ\an\99\r\86¡\94L>¢=ÝqY`\8a¿M\96ÉQ%àt\ 1ê\8e¾·>×4AQicJ%ßy\87\18"\8aI¤À!\9d¹\151@\b\8f\9dcÒ      òµÆ\14\9c\10ÕY\97ïß­£´2ÕÔúP\ 6½»%¡9\ 45\$)õ`L?:\88Çu\14\8eöÑQì\83\84\1e$¹üè \1eÞÍ×â\8då\16\9f\f\17#q\8b
+¤®´¡\829¶¡\14\17ämvL%´M¥\16Q\1c\15\v_6\95Zqu\9b\1d \95_«èràE *\88/\9f*i\93-ÞÑåØ2¸MÅä%\ f¿M  \88Ü6\95\96þ\89\ 3#rÓ\9e,\8a« {4üSöÖ\91gnÁ\1f\8f)\e>`\9aÒ\ 6B³CÆ5Ì\8d\806\1cÅSàò÷cÜ\ f\10¾s\15\ 2\8f\ 1«Ç\89©*8\aÀ¼{wÈ\ 1³ø\81\80¾  \83Ö\ 6     ÂæqHÀ\8f\90@\ f\8f4°çP\15½ï\eßÐA2\90ìD)Kù\80úâRe`L\ÄÞ\ 4:Û­\82ì.PW\ 4+½XEe\99\16\1a¤)\12¢²bÿQµÙê\r\99¬\18[ME\ 4\9b­Þ\82Û\84¸%\88\a\1d\81^èÅ\8fìY,\95qf±[#\90®¥,AQq    \\9c8UÓ\1c\81{ûR\9c\fn¢³3òäRF²Õ{doK½\18r\ 4àÀÖ\1c¾ÕTí8Êãßê\1aö\1a  FÝ1ô\95RË@ÛA\87\83k*4'T\91!\93)\aoTBÖ¬²
+2~ب)D\89Ñ®FS\ 3\ 2ò Ãc\80Ë65\vôe¢Ðø\89>EdL¾S\91é¤\ 2´0a{¬SW\1c*\96\18öÄ'óe¿XϽ\1dî\1dº¨=       -\812b\8cÜÊ~8y\aö\9aê\1aëû?Xli\8eÅýV2nf[þĽùrP}Ï^d'W¤ó\ 3\83Ïu\83=\9a¿âcûÕbã\17ag\18rÇ÷¡&»\86¡\81_\19÷¦B§ ÂM^¤o}ï%\9d\8c<<8ý<HÞ \83Å\1aë@*\1d\e\víÃs\94Ô\v\evF-l¸%\1d¢v\18 \ 2°\9d\15è[ßg&ÙiF}ÃU\95\ f°A+m\89\9e#\94ó§¢×Qv\97¶¶Gh\87\ 5Vt®
+\90\98Û[\89V\855¦,\ra #*p\97\a\193ò*ê«·á§\87\87¶·(<\8ef1\ 2\98\b¢!ÂB`\19\111ïD8|\ 6\97qI\a\8a\9d¢emW/üãR£µ\r\944\ 3ìÂ\17\9b¡GE?R\95kZì Ê­Ï¹M\14h(0qé·\1f\ 3\97©\19bŽ\15Ó*m.ØùaJbG\86ÚÇ[\vl¾IUT-úPM£ºâêr06hù㣩\ 6*uÝ©Yøïq\9a¥\)\19´îw*±)\89\8c;x\r¤\ e§!z\80Ò{\e³Xö¿)ÏÁ\81\16Q¢¿\ eÃû\ 6ü¨ÍÕÛp^\9f¿>¿N~É\9e\84GÍVt½5\19L\8bóáðbø\9fe~ú¸\1a\ f'Ë_ñ_jöܬT\ e£ùáãt0\ 4u\fÜý\81ÝÃ%v4V?a[pf¿\19öì\92Ë?ÅJ£ò^3ÙÏ?i\9d\94«ì\92Íý\17.ð~1ãä\97ße\ fÏI\8f
+ÏÉw\83.'\eÅsN(/d\v\94p-Æ1ø±\ 6T+Ý\8eÓÖt\15ÜË\ fç¹UA:©]å«\15îÜ\92æG\8aº\88\96\17¥$\84è*7lfÔÅóQü¶q\12Ë_çÓ/\89´~¨äıÿܼ­¼å\vÝ{©OZ\1f\8cnjÁfì³ë²\v\ 5o\8b\v\©ÍÉ\97½\ 2'\9f\µ9!Ô÷Â\15FÇøHp¡l¸Á\85T\7f\8f\13_ßR\hrv\83·\8fáMù¯ÁÒ\81J\ fÿs`é@%!\80?\ 4\96\ eTB³ù1°t \92\11\8d\1f\ 1K\a*\ 1\ 4~\f,\1d¨d»ü\bX:ö<üÏ\81¥\ 3\95\90É?\ 6\96\ eT"Ôü\14X:PiÓ\99ÏÀ\92öh$ÊXÝ©\18tw:Ê\90©Ðj3ñ¯Û\ft\18l4\9bmF<½\16 ¯\ 4 Í¬â\rì5eN\16Ó\17\1f´\19\9fmÖOÛ\fÍødG Ð\8d×\ 5\9a\89yiUüù;SêÏ\10y:sH\81\88 ©KA!³©u]l.\80\93Úð÷PÂ¥\88\ 3ÊX{
+ÌÈ\12\1e\9d) XÀ\bd¸[\16}ì0\18­\86L\82£¾¶\97
+\85ßW9.a¬.¾Dáø\8f\94CAúò´J\13Ò~\90Á\ 3v9\80\8aN\1d\88î\ eÃj5\95\94¬#We\ 6ã-\1dïR\85FypY6ïGÙ\81\9b\0A×±\91\w!y)7Û\87à<× V\9e\ 6í\e"W¹ÉZXnÊô[ß[y\87eE¡1ß%#\10\82PJJ\8aÄ\85aÛ:ïjZQ­-æsc\91\81H\1f®(0ù£Ó"îRw\81\95×ÌzáoÍ%*_\82òÓ\91cÀÃãWÑmB~-l\98\90L_º@NF@Ö\10b\9d°3È\92o^o*]Ò\ 6ü$?\9f'§A7|ß\rM\ f¿ð\16\8b¼cB\ez£ê\86\89\91µM¼
\11\93¤.r-\1a¿ÂM"\14ö'º:ø8/#GÂ\94:\ 1ÒD¾"-Tè×ÛÅ]\98à¢\95\ 2wË5Ïï\ 5èý\8e\8cç3(\8böj>\8f\88·X9^*H<ÖO4µ>ô¢ C|çÙÄn<üK0s\15D:á-ÌW÷I\83°e"\10\85\16\ e\1a)\81\0òÎÍk¤\89\15\97\15\ f\89@dÑõãðW¼ãpÛ6\8aöØyÞZ§®à¤:ò\84y,'V       \7f ®¼U¼¿[à'©\b\9b\12\ 6Ù\98Ú§ysü\ eÃ\1f4@\899!¿8·\9dpãvª[·\9dÐ^K \13Éå\82î<ü`¹ ®;.ðð¢y=èYN\80ó¸\9d\80¥û\89\13,\17\ 4}.\17¤ÍÙÔå\82´\90\9f\13\17@&³m©\13XH¶;\ 1Àa¤ÒMÃ\aõ\11s\81±Ò?Ê\ 3¬\17+\13l'¨Nb·¹©Z N\98ç:]Ç    Â\83¯yóI\1e\88\82Ë\8bü\11w\ fqù \95¾4!n\98ØÁ\0f²ÛDðïM¬\e\90\a\12\97]+B\94ÿñ\f6\1f»\17Cß½\86òiY\93οË5Ôï\9c\81t~QûnRé_\eðð[MÈâ\ eÕýUmËA\ fÿ]\13ßï0²ü\89\89]3B¦)Å<ö©\89µ3l\9aPv\bg8s&\b¤'£\89~º¾nâ[I\85\ 6\9c\94\ 2\8fý\9b }\aW:\95Aj\7fÓ\84a\99ØßsÊká-UÍ5=5èèù&áD\83é\15Çƺ\9e´S\8e}u+u\97®ãá¿4\11úf\9e«\8a+Çþ­âÕ\9d\13Äα?Lhß½\86«ëxø\7f»\86ñWg 9¶y\8aðöj+G\92'¦DÏ0OEÃk\ 6\8cÍ®ã ò®\9e0ä¿?Ã\ 6"\eßM*Cù(#þ@䯢aìBnHãÚh[\ e"\eÚ®yùÙ\19ôõ¥±\81\95F\98\r\v0%j\ 3\7ff\81ü0G§2Âô\a~\19(VéJ S\84\15zñ#6öÕ\87\93Âãh\16ÓÔö(dÜ\95\a²¦ög!\9cN}\1e\1eF\89\97\10þ[!3H8ÝòÒé\16\1e~\9e¾\rü:\10úhD$K`\9e\99),ã\12\84Ò\9cÁ2\13¢ËÛÅ\90\f\8a\81°ïèè¾x'v«p\97§^æ9\93¨qs\1c\a\95µÉ½-\bº\ 5&ÿ`\vd· ¥\ fl\81â\b \93åçä\93-Ò\ÿ      ù*/\96àT¤ÓV©æíÛß$\972LX\8f¶ ä\16¼Ç5Ò\93O!wR\ 5ò\ 6)Ðð\8fõò~\rc~jPÛ\ f=Þ¶}&Q\95\87w\1dÓþ,dÓk\9f\11H   eü¦P\95Ç}\13­\9cá.ÈÿõÇr\9d|`f\1f¯»º6l(0@t\8a\92zr>Â~p!\13©!îÇmÇ\(t\17\1djÆÛ9_\90cb/\93Ð.}$s\9c\1c\13Æ0¦\9c7!\8bª~v+ûa\86\82ÿ£½J»\9aJ\82è/xÿ¡\9d\11%\82\9dÞ\17Q4,\ eH\10\ 5\91ÅÃ\84@\9e\fNH0    £|\99ß>·ú%\ fD<&ê\90ã³×ꪺ·ª«7M_ß}M\12«cH¼M^öM\89â\9aDYý½ÿxf{®çæ·ÍË\9a?hM'²«ÊþÖ\9d!\7f÷Þ©ÚY·Þ¯­íì\1c^ÑKU.Zxñ\8dLß¹F\16µ´ò\84RÅNÁnµ´¿*\13ñÕÒñ\86\1d¶ÚÛjغx÷'i¸¨\96+ÍÆ°¥N,  °I\0⥱ÿ\8c$îãs¤ºªÑ®\8bbwãbs(û°²[²m_]Óæp®õ¡\9c03ËowWÈ\96£Ò\96}¼Þê\9eÐ\1fRä^Ê0â\85\9d\9aÂûmo:\1d\80\b¬¥\88\7f0¢áÖùp    \ 2\eݽ\1eXb¦Eu0Mº6\ 6Ï\97Õz@kåþÌü`þ£È?äEu±RIÌ\13ïï\7f¤\9ba\ 5\9f½.\1f\ 6ö³;\aÉÁâý"\9fE\9c¿\9aU\a\17\8fW«§»\ 3N\8aÜ«\9eÎ>\9aIÙIß\9d[~QèP~ÒD6¥\9f¾}¹V°¶üÐÔ6Nñ=Q\9d÷\95\12Õ\ 3ä6\8f\3ÿdf¤òZÁn
+{²e\r¡çß®,\1eþ]k©\85ýí§)Ë\81ÉÕùº\10öhí)-\92×£vá£3\8f_\9flP|>(í«\14i\94ò«¨þ±8[\8c5\7f[=Gw\95\96¼¢º­ÿï|6\97MÕV¥l,wZoòÏ\83¥îñÅYÞ\19dSS\18ÙÊ\a\17ç´À6\16ò\93ÓN½y\99÷2É\8a\9fÀ\8f¾>2©\ 2SÖ¢ci´~\94M§µLVX\1d¯\96FµÖ\e,\9d\1e\ f\9d\92=¢¡Ýõúöê\12\8aµ\r¬\9dcÓÐF4°\1aS\156\8buа\91  VÿÝOøld\82\vüi\9cýíFñÛmfb¨)v_¢ó\ 2\8d\ f\18úÄ\f[gï\ e\ 4k\91àÍÌ1iØYf\9d¡F=5\94·h¹ô\7f»XQÏÞcý&t°J\19¥q¢Q.ú@\rá\83\83S\1a\1a\93©\11\83 )«¤u\91íÖ2\ 5\1dÞIÅ\92
+ÆX.\9d³LÆÈ-ô0Aòè\f\94q\9a\vk<³\1a»\99\14\86«`\143Aq¡\94eNa§gÇ\99Ñ\11S^\ 2        .t\94L«À½\89Ì9î¤WLEÍ\81\12r\9c)g¸\91\ 2¶iÃ\9d\85A0\8bǨ=T\81ä\10\87IØÌ\94Ö\E\98x\9cié°Ê\90o\¡9¤pe\ 4\8e\81$\11e`7\8c:ÎúY\95ÈFD\ 3\ 5\ 4«>ïåùv§Õ\ 5Щ×<ËW;­ü3ú\92\ 6ÝÞå¨?\97e\84Ú\b1`Ö\ 2\15¶»3\ 4$\ 4M\87        î]\94îVv$ÆÂ÷R°õLÂO\0VY\r\7fKí¹\ fÁ¥®ô\12[\9c.:As-a4u\16³­!\ 5Ç>­\99\19\aîb\80w¬K\0ËP\ eh°êjÞ\90¯Ú77\ñnb3\7fúäI`S_ÃFæß\ e\98t&\92%B;bra\82\96F\93        ÜÑ\9f§\8d%`¤¤#\13\fÈ\8a\1dJK.#\81ä\90\80\94\ 3\84\16T\8e\ 6Ä%h\rpDX\\87mÜ3\87°E
+:e4\ f\9a\ 4Hn\93\16ð\\1cR_i\97æÛ7Ö\13hã»N|íº\en\e_\96þ®¬\1f\8d\19UX\17à%à "\19
+7ZÏ\83×ä\18.µõhp/"R\80/\16 \15\ 5\19Ì\8f\aP)ISVRÄ\ 2c\ 3À°\94§y\88\8a ¹:Ïrå\10Îí¯7N\86\8aù\85¨È[\92Ú/\89\f
+]Yð\922<]d*Rv\ 3÷GäÔR\11\18\17\82-/\a\89KAG\0\8co\8a\9b ÎK\q­Ä\10Ø\17×´øÂ\8c\92=\8e\e\17\15ì(/\1a\EÜÓåS\9fHQ?\96¢ãË\vÿ\13\84Z\aºÞ=@²"\90á\ 17\12\16!·9®\8d÷Ì\b \8caÔ!\91k-$3
+E\0®f&%î|\v¾ÿp¦C\15Cç+Y\94\1f \89Ñtu\vÏ\8d\17\9eb\vghå\14\ e\v(q$Ý\15×wM\16WqL?\8eM\1e\8dø\16\12EÍ5\1f\92Ç,ÂAJÊ7ÞOÈ\1dyKJþy\96\e\14r\ eáÇ\10y(ì"U\9d\ 2\ 1\19\11\98©à\1c!ø}\89\ 5tV@\10
+BªfHV,`Ò\96®*à\16Sc$¿ýÅúÉ@³c\806¶æ\84\923E:/ù%P7\9a"\9f\vIºË\84#\bß¾¹\8dô\a§)³áj\96Æ\91\v´\12CI\ 1¥/\8dÕ3-\\92\14Q\12\80\11í\9b»R\815IÐh-Ó~\94ç\1eÅ6N\ 5®EÌ S    \13\ 3\9dZj\82\12Ø\19A\17Ò\8d\8dtp}¡xeáÍ\95ÞB\ f\1fâ\ 1öªy\92¿é5OÛxs\9dô\9bÿä¬Ùét\aÍA~\8e\19vÒËûÀ"gý¿º\9fh\ 4[FËñzÛx\9eý'À\0=6©&\rendstream\rendobj\r7 0 obj\r[6 0 R]\rendobj\r25 0 obj\r<</CreationDate(D:20121108194719-08'00')/Creator(Adobe Illustrator CS4)/ModDate(D:20121108194719-08'00')/Producer(Adobe PDF library 9.00)/Title(release_seq_final)>>\rendobj\rxref\r0 26\r0000000000 65535 f\r
+0000000016 00000 n\r
+0000000144 00000 n\r
+0000021707 00000 n\r
+0000000000 00000 f\r
+0000024726 00000 n\r
+0000024540 00000 n\r
+0000074969 00000 n\r
+0000021758 00000 n\r
+0000022120 00000 n\r
+0000028374 00000 n\r
+0000028261 00000 n\r
+0000023430 00000 n\r
+0000023979 00000 n\r
+0000024027 00000 n\r
+0000024610 00000 n\r
+0000024641 00000 n\r
+0000025124 00000 n\r
+0000025502 00000 n\r
+0000028448 00000 n\r
+0000028656 00000 n\r
+0000029633 00000 n\r
+0000034894 00000 n\r
+0000051182 00000 n\r
+0000065251 00000 n\r
+0000074992 00000 n\r
+trailer\r<</Size 26/Root 1 0 R/Info 25 0 R/ID[<63737B81A31342A2823862AFD0ADED1C><DEF487BD94C84468BA957884F4DCC19C>]>>\rstartxref\r75173\r%%EOF\r
\ No newline at end of file
diff --git a/correctness-model/writeup/figures/rmw_atomicity.dot b/correctness-model/writeup/figures/rmw_atomicity.dot
new file mode 100644 (file)
index 0000000..8b1547c
--- /dev/null
@@ -0,0 +1,12 @@
+digraph rmw_atomicity {
+margin=0;
+ranksep=.1;
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="B: v.rmw()", shape=none];
+N3 [label="C: v.store(2)", shape=none];
+
+N1 -> N2 [label="rf", color=red];
+N1 -> N3 [label="mo", color="#00aa00", weight=100];
+N2 -> N3 [color=invis];
+}
diff --git a/correctness-model/writeup/figures/rmw_atomicity2.dot b/correctness-model/writeup/figures/rmw_atomicity2.dot
new file mode 100644 (file)
index 0000000..483367c
--- /dev/null
@@ -0,0 +1,13 @@
+digraph rmw_atomicity2 {
+margin=0;
+ranksep=.1;
+
+//N1 [label="A: v.store(1)", shape=none, group="a"];
+N1 [style=invis, shape=none];
+N2 [label="B: v.rmw()", shape=none];
+N3 [label="C: v.store(2)", shape=none];
+
+N1 -> N2 [color=invis];
+N1 -> N3 [color=invis, weight=100];
+N2 -> N3 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+}
diff --git a/correctness-model/writeup/figures/rmw_mo.dot b/correctness-model/writeup/figures/rmw_mo.dot
new file mode 100644 (file)
index 0000000..7a41997
--- /dev/null
@@ -0,0 +1,9 @@
+digraph rmw_mo {
+margin=0
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="B: v.rmw()", shape=none];
+
+N1 -> N2 [label="rf", color=red];
+N1 -> N2 [color=invis, constraint=false];
+}
diff --git a/correctness-model/writeup/figures/rmw_mo2.dot b/correctness-model/writeup/figures/rmw_mo2.dot
new file mode 100644 (file)
index 0000000..0d4ce57
--- /dev/null
@@ -0,0 +1,8 @@
+digraph rmw_mo2 {
+margin=0
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="B: v.rmw()", shape=none];
+
+N1 -> N2 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+}
diff --git a/correctness-model/writeup/figures/rr_mo.dot b/correctness-model/writeup/figures/rr_mo.dot
new file mode 100644 (file)
index 0000000..179991e
--- /dev/null
@@ -0,0 +1,13 @@
+digraph rr_mo {
+margin=0
+
+N1 [label="X: v.store(1)", shape=none];
+N2 [label="Y: v.store(2)", shape=none];
+N3 [label="A: v.load()", shape=none];
+N4 [label="B: v.load()", shape=none];
+
+N3 -> N4 [label="hb", color=blue];
+N1 -> N3 [label="rf", color=red, constraint=false];
+N2 -> N4 [label="rf", color=red, constraint=false];
+N1 -> N2 [color=invis];
+}
diff --git a/correctness-model/writeup/figures/rr_mo2.dot b/correctness-model/writeup/figures/rr_mo2.dot
new file mode 100644 (file)
index 0000000..fa0a6f7
--- /dev/null
@@ -0,0 +1,8 @@
+digraph rr_mo {
+margin=0
+
+N1 [label="X: v.store(1)", shape=none];
+N2 [label="Y: v.store(2)", shape=none];
+
+N1 -> N2 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+}
diff --git a/correctness-model/writeup/figures/rw_mo.dot b/correctness-model/writeup/figures/rw_mo.dot
new file mode 100644 (file)
index 0000000..a8e99fe
--- /dev/null
@@ -0,0 +1,11 @@
+digraph rw_mo {
+margin=0;
+ranksep=.3;
+
+N1 [label="X: v.store(1)", shape=none];
+N2 [label="A: v.load()", shape=none];
+N3 [label="B: v.store(2)", shape=none];
+
+N2 -> N3 [label="hb", color=blue];
+N1 -> N2 [label="rf", color=red, constraint=false];
+}
diff --git a/correctness-model/writeup/figures/rw_mo2.dot b/correctness-model/writeup/figures/rw_mo2.dot
new file mode 100644 (file)
index 0000000..e7f611a
--- /dev/null
@@ -0,0 +1,12 @@
+digraph rw_mo2 {
+margin=0;
+ranksep=.3;
+
+N1 [label="X: v.store(1)", shape=none];
+N2 [label="A: v.load()", shape=none, fontcolor=invis];
+N3 [label="B: v.store(2)", shape=none];
+
+N2 -> N3 [color=invis];
+N1 -> N2 [color=invis, constraint=false];
+N1 -> N3 [label="mo", color="#00aa00", style=dashed, penwidth=3, constraint=false];
+}
diff --git a/correctness-model/writeup/figures/sc_mo.dot b/correctness-model/writeup/figures/sc_mo.dot
new file mode 100644 (file)
index 0000000..5d5f6b1
--- /dev/null
@@ -0,0 +1,9 @@
+digraph sc_mo {
+margin=0
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="B: v.store(2)", shape=none];
+
+N1 -> N2 [label="sc", color=purple];
+N1 -> N2 [color=invis, constraint=false];
+}
diff --git a/correctness-model/writeup/figures/sc_mo2.dot b/correctness-model/writeup/figures/sc_mo2.dot
new file mode 100644 (file)
index 0000000..a7d37c3
--- /dev/null
@@ -0,0 +1,8 @@
+digraph sc_mo2 {
+margin=0
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="B: v.store(2)", shape=none];
+
+N1 -> N2 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+}
diff --git a/correctness-model/writeup/figures/sc_wr_mo.dot b/correctness-model/writeup/figures/sc_wr_mo.dot
new file mode 100644 (file)
index 0000000..49a5f03
--- /dev/null
@@ -0,0 +1,13 @@
+digraph sc_wr_mo {
+margin=0;
+ranksep=.3;
+
+N1 [label="X: v.store(2)", shape=none];
+N2 [label="A: v.store(1, seq_cst)", shape=none];
+N3 [label="B: v.load(seq_cst)", shape=none];
+
+N2 -> N3 [label="sc", color=purple];
+N1 -> N3 [label="rf", color=red];
+N2 -> N1 [color=invis, constraint=false];
+{rank=same; N1 N3}
+}
diff --git a/correctness-model/writeup/figures/sc_wr_mo2.dot b/correctness-model/writeup/figures/sc_wr_mo2.dot
new file mode 100644 (file)
index 0000000..7efd810
--- /dev/null
@@ -0,0 +1,13 @@
+digraph sc_wr_mo2 {
+margin=0;
+ranksep=.3;
+
+N1 [label="X: v.store(2)", shape=none];
+N2 [label="A: v.store(1, seq_cst)", shape=none];
+N3 [label="B: v.load(seq_cst)", shape=none, fontcolor=invis];
+
+N2 -> N3 [color=invis];
+N1 -> N3 [color=invis];
+N2 -> N1 [label="mo", color="#00aa00", style=dashed, penwidth=3, constraint=false];
+{rank=same; N1 N3}
+}
diff --git a/correctness-model/writeup/figures/specdesign.pdf b/correctness-model/writeup/figures/specdesign.pdf
new file mode 100644 (file)
index 0000000..203ab8d
Binary files /dev/null and b/correctness-model/writeup/figures/specdesign.pdf differ
diff --git a/correctness-model/writeup/figures/specworkflow.pdf b/correctness-model/writeup/figures/specworkflow.pdf
new file mode 100644 (file)
index 0000000..72c4c78
Binary files /dev/null and b/correctness-model/writeup/figures/specworkflow.pdf differ
diff --git a/correctness-model/writeup/figures/wf_sc_rf.dot b/correctness-model/writeup/figures/wf_sc_rf.dot
new file mode 100644 (file)
index 0000000..95116d3
--- /dev/null
@@ -0,0 +1,16 @@
+digraph wf_sc_rf {
+margin=0
+ranksep=.3;
+
+N1 [label="A: v.store(1, seq-cst)", shape=none];
+N2 [label="X: fence(seq-cst)", shape=none];
+N3 [label="B: v.store(2)", shape=none];
+N4 [label="Y: v.load()", shape=none];
+
+//N1 -> N3 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+N1 -> N2 [label="sc", color=purple];
+N2 -> N4 [label="sb", color=blue, weight=100];
+N3 -> N4 [label="rf", color=red];
+N1 -> N3 [style=invis];
+{rank=same; N3 N4}
+}
diff --git a/correctness-model/writeup/figures/wf_sc_rf2.dot b/correctness-model/writeup/figures/wf_sc_rf2.dot
new file mode 100644 (file)
index 0000000..1cdc907
--- /dev/null
@@ -0,0 +1,16 @@
+digraph wf_sc_rf2 {
+margin=0
+ranksep=.3;
+
+N1 [label="A: v.store(1, seq-cst)", shape=none];
+//N2 [label="X: fence(seq-cst)", shape=none];
+N3 [label="B: v.store(2)", shape=none];
+//N4 [label="Y: v.load()", shape=none];
+
+N1 -> N3 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+//N1 -> N2 [label="sc", color=purple];
+//N2 -> N4 [label="sb", color=blue];
+//N3 -> N4 [label="rf", color=red, constraint=false];
+//N1 -> N3 [style=invis];
+//{rank=same; N1 N2}
+}
diff --git a/correctness-model/writeup/figures/workflow.pdf b/correctness-model/writeup/figures/workflow.pdf
new file mode 100644 (file)
index 0000000..1c852cf
Binary files /dev/null and b/correctness-model/writeup/figures/workflow.pdf differ
diff --git a/correctness-model/writeup/figures/wr_mo.dot b/correctness-model/writeup/figures/wr_mo.dot
new file mode 100644 (file)
index 0000000..d8267be
--- /dev/null
@@ -0,0 +1,13 @@
+digraph wr_mo {
+margin=0;
+ranksep=.3;
+
+N1 [label="X: v.store(2)", shape=none];
+N2 [label="A: v.store(1)", shape=none];
+N3 [label="B: v.load()", shape=none];
+
+N2 -> N3 [label="hb", color=blue];
+N1 -> N3 [label="rf", color=red];
+N2 -> N1 [color=invis, constraint=false];
+{rank=same; N1 N3}
+}
diff --git a/correctness-model/writeup/figures/wr_mo2.dot b/correctness-model/writeup/figures/wr_mo2.dot
new file mode 100644 (file)
index 0000000..182dea6
--- /dev/null
@@ -0,0 +1,13 @@
+digraph wr_mo2 {
+margin=0;
+ranksep=.3;
+
+N1 [label="X: v.store(2)", shape=none];
+N2 [label="A: v.store(1)", shape=none];
+N3 [label="B: v.load()", shape=none, fontcolor=invis];
+
+N2 -> N3 [color=invis];
+N1 -> N3 [color=invis];
+N2 -> N1 [label="mo", color="#00aa00", style=dashed, penwidth=3, constraint=false];
+{rank=same; N1 N3}
+}
diff --git a/correctness-model/writeup/figures/ww_mo.dot b/correctness-model/writeup/figures/ww_mo.dot
new file mode 100644 (file)
index 0000000..2e00cd9
--- /dev/null
@@ -0,0 +1,9 @@
+digraph ww_mo {
+margin=0
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="B: v.store(2)", shape=none];
+
+N1 -> N2 [label="hb", color=blue];
+N1 -> N2 [color=invis, constraint=false];
+}
diff --git a/correctness-model/writeup/figures/ww_mo2.dot b/correctness-model/writeup/figures/ww_mo2.dot
new file mode 100644 (file)
index 0000000..149c113
--- /dev/null
@@ -0,0 +1,8 @@
+digraph ww_mo2 {
+margin=0
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="B: v.store(2)", shape=none];
+
+N1 -> N2 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+}
diff --git a/correctness-model/writeup/figures/ww_sc_fence_first_collapse.dot b/correctness-model/writeup/figures/ww_sc_fence_first_collapse.dot
new file mode 100644 (file)
index 0000000..c85988c
--- /dev/null
@@ -0,0 +1,17 @@
+digraph ww_sc_fence_first_collapse {
+margin=0
+ranksep=.3;
+
+N1 [label="A: v.store(1, seq-cst)", shape=none];
+//N2 [label="X: fence(seq-cst)", shape=none];
+N3 [label="Y: fence(seq-cst)", shape=none];
+N4 [label="B: v.store(2)", shape=none];
+N5 [style=invis, shape=point];
+
+//N1 -> N4 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+N1 -> N3 [label="sc", color=purple];
+N3 -> N4 [label="sb", color=blue, weight=100];
+N1 -> N5 [style=invis];
+N5 -> N4 [style=invis];
+{rank=same; N4 N5}
+}
diff --git a/correctness-model/writeup/figures/ww_sc_fence_first_collapse2.dot b/correctness-model/writeup/figures/ww_sc_fence_first_collapse2.dot
new file mode 100644 (file)
index 0000000..17d14a0
--- /dev/null
@@ -0,0 +1,14 @@
+digraph ww_sc_fence_first_collapse2 {
+margin=0
+//ranksep=.3;
+
+N1 [label="A: v.store(1, seq-cst)", shape=none];
+N2 [style=invis, shape=point];
+N3 [style=invis, shape=point];
+N4 [label="B: v.store(2)", shape=none];
+
+N1 -> N4 [label="mo", color="#00aa00", style=dashed, penwidth=3, constraint=false];
+N1 -> N2 [color=invis, weight=100];
+N3 -> N4 [color=invis, weight=100];
+{rank=same; N2 N3}
+}
diff --git a/correctness-model/writeup/figures/ww_sc_fence_mo.dot b/correctness-model/writeup/figures/ww_sc_fence_mo.dot
new file mode 100644 (file)
index 0000000..3edead9
--- /dev/null
@@ -0,0 +1,18 @@
+digraph ww_sc_fence_mo {
+margin=0
+ranksep=.3;
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="X: fence(seq-cst)", shape=none];
+N3 [label="Y: fence(seq-cst)", shape=none];
+N4 [label="B: v.store(2)", shape=none];
+N5 [style=invis, shape=point];
+
+//N1 -> N4 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+N2 -> N3 [label="sc", color=purple];
+N1 -> N2 [label="sb", color=blue, weight=100];
+N3 -> N4 [label="sb", color=blue, weight=100];
+N2 -> N5 [style=invis];
+N5 -> N4 [style=invis];
+{rank=same; N4 N5}
+}
diff --git a/correctness-model/writeup/figures/ww_sc_fence_mo2.dot b/correctness-model/writeup/figures/ww_sc_fence_mo2.dot
new file mode 100644 (file)
index 0000000..f1964fd
--- /dev/null
@@ -0,0 +1,14 @@
+digraph ww_sc_fence_mo2 {
+margin=0
+//ranksep=.3;
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [style=invis, shape=point];
+N3 [style=invis, shape=point];
+N4 [label="B: v.store(2)", shape=none];
+
+N1 -> N4 [label="mo", color="#00aa00", style=dashed, penwidth=3, constraint=false];
+N1 -> N2 [color=invis, weight=100];
+N3 -> N4 [color=invis, weight=100];
+{rank=same; N2 N3}
+}
diff --git a/correctness-model/writeup/figures/ww_sc_fence_second_collapse.dot b/correctness-model/writeup/figures/ww_sc_fence_second_collapse.dot
new file mode 100644 (file)
index 0000000..6dde5c5
--- /dev/null
@@ -0,0 +1,17 @@
+digraph ww_sc_fence_second_collapse {
+margin=0
+ranksep=.3;
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [label="X: fence(seq-cst)", shape=none];
+//N3 [label="Y: fence(seq-cst)", shape=none];
+N4 [label="B: v.store(2, seq-cst)", shape=none];
+N5 [style=invis, shape=point];
+
+//N1 -> N4 [label="mo", color="#00aa00", style=dashed, penwidth=3];
+N2 -> N4 [label="sc", color=purple];
+N1 -> N2 [label="sb", color=blue, weight=100];
+N2 -> N5 [style=invis];
+N5 -> N4 [style=invis];
+{rank=same; N4 N5}
+}
diff --git a/correctness-model/writeup/figures/ww_sc_fence_second_collapse2.dot b/correctness-model/writeup/figures/ww_sc_fence_second_collapse2.dot
new file mode 100644 (file)
index 0000000..e7c0b35
--- /dev/null
@@ -0,0 +1,14 @@
+digraph ww_sc_fence_second_collapse2 {
+margin=0
+//ranksep=.3;
+
+N1 [label="A: v.store(1)", shape=none];
+N2 [style=invis, shape=point];
+N3 [style=invis, shape=point];
+N4 [label="B: v.store(2, seq-cst)", shape=none];
+
+N1 -> N4 [label="mo", color="#00aa00", style=dashed, penwidth=3, constraint=false];
+N1 -> N2 [color=invis, weight=100];
+N3 -> N4 [color=invis, weight=100];
+{rank=same; N2 N3}
+}
diff --git a/correctness-model/writeup/formalization.tex b/correctness-model/writeup/formalization.tex
new file mode 100644 (file)
index 0000000..aecb783
--- /dev/null
@@ -0,0 +1,92 @@
+\mysection{Formalization of Correctness Model}\label{sec:formalization}
+
+Unlike the SC memory model, applying linearizability can be complicated under
+C/C++ by the fact that the C/C++ memory model allows atomic loads to read from
+atomic stores that appear later in the trace and that it is in general
+impossible to produce a sequential history that preserves program order for the
+C/C++ memory model. Intuitively however, we can weaken some constraints, e.g.
+the \textit{happens-before} edges in some cases, to generate a reordering of
+ordering points such that they yield a sequential history that is consistent
+with the specification. We formalize our approach as follow.
+
+We represent a trace as an \textit{execution graph}, where each node represents
+each API method call with a set of ordering points, and edges between nodes are
+derived from the \textit{happens-before} edges and the \textit{modification
+order} edges between ordering points. We define \textit{opo} as the
+\textit{ordering point order} relation between ordering point.  Given two
+operations $X$ and $Y$ that are both ordering points, the \textit{modification
+order} edges are as follow:
+
+\squishcount
+
+\item {\bf Modification Order (write-write):} $X \xrightarrow{mo} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (read-write):} $A \xrightarrow{mo} Y \ \wedge \  A \xrightarrow{rf} X \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (write-read):} $X \xrightarrow{mo} B \ \wedge \  B \xrightarrow{rf} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (read-read):} $A \xrightarrow{mo} B \ \wedge \  A \xrightarrow{rf} X \ \wedge \  B \xrightarrow{rf} Y \Rightarrow X \xrightarrow{opo} Y$.
+\countend
+
+\vspace{0.3cm}
+
+Intuitively, if method $A$ 
+
+In order to relax the contraints on the original execution graph, we define an
+action \textit{tranform} that can be performed on the graph as follow:
+
+\mypara{{\bf Hoisting loads:}} $ \forall X, Y, X \in
+\textit{OrderingPoints}\xspace \wedge Y \in \textit{OrderingPoints}\xspace \wedge
+address(X)\not=address(Y) \wedge
+X \relation{hb} Y \wedge Y \in \textit{LoadOps}\xspace
+\Rightarrow \forall Z, Z
+$.
+
+
+\begin{figure}[!htbp]
+\begin{algorithmic}[1]
+\Function{InferParams}{testcases, initialParams}
+\State inputParams := initialParams
+\If{inputParams is empty}
+\State inputParams := the weakest parameters \label{line:startWithRelaxed}
+\EndIf
+\ForAll{test case $t$ in testcases}
+\State candidates := inputParams \label{line:setOfCandidates}
+\State results := \{\}
+\While{candidates is not empty}
+\State Candidate $c$ := pop from candidates
+\State run \cdschecker with $c$ and check SC \label{line:findSCViolation}
+\If{$\exists$ SC violation $v$}
+\State \Call {StrengthenParam}{$v$, $c$, candidates} \label{line:callStrengthenParam}
+\Else
+\State results += \Call {WeakenOrderParams}{$c$} \label{line:weakenOrderParams}
+\EndIf
+\EndWhile
+\State inputParams := results \label{line:tmpOutputAsInput}
+\EndFor
+\State \Return{results} \label{line:finalResults}
+\EndFunction
+
+\Procedure{StrengthenParam}{v, c, candidates}
+\While{$\exists$ a fix $f$ for violation $v$}
+\State possible\_repairs := strengthen $c$ with fix $f$ \label{line:strengthenParam}
+\State candidates += possible\_repairs \label{line:possibleFixes}
+\EndWhile
+\EndProcedure
+
+\end{algorithmic}
+\caption{\label{fig:algorithmfence}Algorithm for inferring order parameters}
+\end{figure}
+
+
+
+\mypara{\bf Generating the Reordering:}
+The \TOOL checker first builds an execution graph where the nodes are
+method calls and the edges represent the
+$\reltext{opo}$ ordering of the ordering points of the methods that
+correspond to the source and destination nodes.  Assuming the absence
+of cycles in the execution graph, 
+the $\reltext{opo}$ ordering is used to generate the sequential history.
+The \TOOL checker 
+topologically sorts the graph to generate the equivalent sequential
+execution.
diff --git a/correctness-model/writeup/implementation.tex b/correctness-model/writeup/implementation.tex
new file mode 100644 (file)
index 0000000..bac8f73
--- /dev/null
@@ -0,0 +1,151 @@
+\mysection{Implementation}\label{sec:implementation}
+
+The goal of the \TOOL specification language is to
+enable developers to write specifications against which concurrent data structures can be tested.
+We can ensure a concurrent data structure is correct with
+respect to an equivalent sequential data structure if for each
+execution of the concurrent data structure, the equivalent sequential
+history for the equivalent sequential data structure yields the same
+results.
+
+The execution space for many concurrent data
+structures is unbounded, meaning that in practice we cannot 
+verify correctness by checking individual executions. However, the
+specifications can be used for unit testing.  In practice,
+many bugs can be exposed by model checking unit tests for 
+concurrent data structures.  We have implemented the \TOOL checker as a
+unit testing tool built upon the \cdschecker framework.  \TOOL
+can exhaustively explore all behaviors for unit tests and provide
+developers with diagnostic reports for executions that violate their
+specification.
+
+
+\mysubsection{Model Checker Framework}
+
+The \TOOL checker takes as input a complete execution from the
+\cdschecker model checker.  The \cdschecker framework operates at the abstraction level of
+individual atomic operations and thus has neither information about
+method calls nor which atomic operations serve as ordering points.
+Thus, we extend the framework by adding {\it annotation} operations to
+\cdschecker's traces, which record the necessary information to check the specifications
+but have no effect on other operations.  The \TOOL compiler
+inserts code to generate the annotation actions to communicate to the \TOOL checker
+plugin the critical events for checking the \TOOL specification.
+These annotation actions then appear in \cdschecker's list of atomic
+operations and make it convenient for  \TOOL to construct
+a sequential history from the execution because for any given method
+call, its invocation event, its ordering points, and its response event are
+sequentially ordered in the list. 
+
+\mysubsection{Specification Compiler}
+
+The specification compiler translates an annotated
+C/C++ program into an instrumented C/C++ program that will generate
+execution traces containing the dynamic information needed to construct the sequential history
+and check the specification assertions.  We next
+describe the type of annotation actions that the \TOOL compiler
+inserts into the instrumented program.
+
+\mypara{\bf Ordering Points:} Ordering points have a conditional guard expression
+and a label. Potential ordering point annotation actions are 
+inserted immediately after the atomic operation that serves as 
+the potential ordering point.  Ordering point check annotation actions are
+inserted where they appear.
+
+\mypara{\bf Method Boundary:} To identify a method's boundaries, \TOOL
+inserts {\it method\_begin} and {\it method\_end} annotations at the
+beginning and end of methods.
+
+\mypara{\bf Sequential States and Methods:} Since checking occurs
+after \cdschecker has completed an execution, the annotation
+actions stores the values of any variables in the concurrent data
+structure that the annotations reference.
+
+\mypara{\bf Side Effects and Assertions:} Side effects and assertions perform
+their checks after an execution.  The side effects and assertions are compiled
+into methods and the equivalent sequential data structure's states are accessible to these methods.
+With this encapsulation,
+the \TOOL checker simply calls these functions to implement the side effects and assertions.
+
+\mypara{\bf Synchronization Checks:} The \TOOL checker performs
+synchronization checks in two parts: compiling the rules and runtime data
+collection.  First, the \TOOL compiler numbers all methods and happens-before
+checks uniquely. For example, the rule ``\code{Update->Read}'' can be represented as (1, 0, 2, 0),
+which means instances of method 1 that satisfy condition 0 should {\it
+  synchronize with} instances method 2 that satisfy condition 0. In this case,
+  condition 0 means \code{true}. Then,
+the \TOOL compiler generates code that communicates the
+synchronization rules by passing an array of integer pairs.  Runtime
+collection is then implemented by performing the condition check at
+each method invocation or response and then passing the method number
+and happens before condition if the check is satisfied.
+
+\mysubsection{Dynamic Checking}
+
+At this point, we have an execution trace with the necessary
+annotations to construct a sequential history and to check
+the execution's correctness.  However, before constructing the
+sequential history, the \TOOL plugin first collects
+the necessary information for each method call, which is the {\it
+  method\_begin} annotation, the ordering point annotations, the
+happens-before checks, and the {\it method\_end} annotations.  Since
+all of the operations in the trace have thread
+identifiers it is straightforward to extract the operations between the {\it
+  method\_begin} and {\it method\_end} annotations.  
+
+\mypara{\bf Reorder Method Calls:} As discussed above, determining the
+ordering of the ordering points is non-trivial under the C/C++ memory
+model. This can be complicated by the fact that the C/C++ memory model
+allows atomic loads to read from atomic stores that appear later in
+the trace and that it is in general impossible to produce a sequential
+history that preserves program order for the C/C++ memory model.
+
+However, we can still leverage the reads-from relation and the
+modification-order relation to order the ordering points that appear
+in typical data structures.  \TOOL uses the following rules to
+generate an ordering-point ordering $\reltext{opo}$ relation on
+ordering points. Given two operations $X$ and $Y$ that are both
+ordering points:
+
+\squishcount
+\item {\bf Reads-From:} $X \xrightarrow{rf} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (write-write):} $X \xrightarrow{mo} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (read-write):} $A \xrightarrow{mo} Y \ \wedge \  A \xrightarrow{rf} X \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (write-read):} $X \xrightarrow{mo} B \ \wedge \  B \xrightarrow{rf} Y \Rightarrow X \xrightarrow{opo} Y$.
+
+\item {\bf Modification Order (read-read):} $A \xrightarrow{mo} B \ \wedge \  A \xrightarrow{rf} X \ \wedge \  B \xrightarrow{rf} Y \Rightarrow X \xrightarrow{opo} Y$.
+\countend
+
+\mypara{\bf Generating the Reordering:}
+The \TOOL checker first builds an execution graph where the nodes are
+method calls and the edges represent the
+$\reltext{opo}$ ordering of the ordering points of the methods that
+correspond to the source and destination nodes.  Assuming the absence
+of cycles in the execution graph, 
+the $\reltext{opo}$ ordering is used to generate the sequential history.
+The \TOOL checker 
+topologically sorts the graph to generate the equivalent sequential
+execution. 
+
+When \TOOL fails to order two ordering points, the operations often commute. Thus,
+if multiple histories satisfy the constraints of \reltext{opo}, by default we generally randomly select one.  However, when those operations
+do not commute, we provide developers with different options: (1) they can
+add additional ordering points to order the two nodes or
+(2) they can run \TOOL in either of the following modes: (a) \textit{loosely
+exhaustive} mode --- \TOOL explores
+all possible histories and only requires that there exists some history that passes the checks or
+(b) \textit{strictly exhaustive} mode --- \TOOL explores all possible histories and requires all histories pass the checks.
+
+
+\mypara{\bf Synchronization Checks:} Synchronization properties are
+specified using the IDs and conditions of method calls, and we have that information
+available after \TOOL constructs the sequential history and checks the preconditions
+and postconditions. For two specific method calls $c_1$ and $c_2$, we can ensure
+$c_1$ synchronizes with $c_2$ by ensuring the annotation \code{c1\_begin}
+happens-before the annotation \code{c2\_end} because any operations
+sequenced-before \code{c1\_begin} should happen-before any operations
+sequenced-after \code{c2\_end} according to the C/C++11 memory model.
+
diff --git a/correctness-model/writeup/introduction.tex b/correctness-model/writeup/introduction.tex
new file mode 100644 (file)
index 0000000..e0c9c70
--- /dev/null
@@ -0,0 +1,226 @@
+\mysection{Introduction}\label{sec:introduction}
+
+Concurrent data structure design can improve scalability by supporting
+multiple simultaneous operations, reducing memory coherence traffic, and reducing the time taken by an
+individual data structure operation.  Researchers have developed many concurrent
+data structure designs with these goals~\cite{rcu,
+lockfreequeue}.  Concurrent data structures often use sophisticated techniques
+including low-level atomic instructions (e.g., compare and
+swap), careful reasoning about the order of loads and
+stores, and fine-grained locking.    For example, while the standard Java hash
+table implementation can limit scalability to a handful of cores,
+more sophisticated concurrent hash tables can scale to many hundreds of
+cores~\cite{javaConcurrentHashMap}.  
+
+The C/C++ standard committee extended the C and C++ languages with
+support for low-level atomic operations in the C/C++11
+standard~\cite{cpp11spec, c11spec, boehmpldi} to enable developers to
+write portable implementations of concurrent data structures.  To support the relaxations typically performed by compilers and processors, 
+the
+C/C++ memory model provides weaker semantics than sequential
+consistency~\cite{scmemorymodel} and as a result, correctly using
+these operations is challenging.  Developers must not only
+reason about potential interleavings, but also about how the processor
+and compiler might reorder memory operations.  Even experts make
+subtle errors when reasoning about such memory models.
+
+Researchers have developed tools for exploring the behavior of code
+under the C/C++ memory model including \cdschecker~\cite{cdschecker}, {\sc
+Cppmem}~\cite{c11popl}, and Relacy~\cite{relacy}.  These tools explore
+behaviors that are allowed under the C/C++ memory model.  While these
+tools can certainly be useful for exploring executions, they can be
+challenging to use for testing as they don't provide support (other
+than assertions) for specifying the behavior of data structures.
+Using assertions can be challenging as different interleavings or
+reorderings legitimately produce different behaviors, and it can be
+very difficult to code assertions to check the output of a test case for an
+arbitrary (unknown) execution.
+
+This paper presents \TOOL, a specification language and specification
+checking tool that is designed to be used in conjunction with model
+checking tools.  We have implemented it as a plugin for
+the \cdschecker model checker.
+
+\mysubsection{Background on Specifying the Correctness of Concurrent Data Structures}
+
+Researchers have developed several techniques for specifying
+correctness properties of concurrent data structures written for strong memory
+models.  While these techniques cannot handle the behaviors typically
+exhibited by relaxed data structure implementations, they provide insight into
+intuitive approaches to specifying concurrent data structure behavior.
+
+One approach for specifying the correctness of concurrent data
+structures is in terms of equivalent sequential executions of either
+the concurrent data structure or a simplified sequential version.  The
+problem then becomes how do we map a concurrent execution to an equivalent
+sequential execution?  A common criterion is {\it
+  linearizability} --- linearizability simply states that a concurrent
+operation can be viewed as taking effect at some time between its
+invocation and its return (or response)~\cite{linearizableref}.
+
+An {\it equivalent sequential data structure} is a sequential version
+of a concurrent data structure that can be used to express correctness
+properties by relating executions of the original concurrent data
+structure with executions of the equivalent sequential data structure.
+The equivalent sequential data structure is often simpler, and in
+many cases one can simply use existing well-tested implementations from the
+STL library.
+
+An execution {\it history} is a total order of method invocations and
+responses. A {\it sequential history} is one where all invocations are
+followed by the corresponding responses immediately. A concurrent
+execution is correct if its behavior is consistent with its equivalent
+sequential history replayed on the equivalent sequential data
+structure. A concurrent object is linearizable if for all executions:
+\squishcount
+\item Each method call appears to take effect instantaneously at some
+  point between its invocation and response.
+
+\item The invocations and responses can be reordered to yield a
+  sequential history under the rule that an invocation cannot be
+  reordered before the preceding responses.
+
+\item The concurrent execution yields the same behavior as
+  the sequential history.
+\countend
+
+A weaker variation of linearization is {\it sequential
+consistency}\footnote{It is important to note that the term sequential
+consistency in the literature is applied to both the consistency model
+that data structures expose clients to as well as the guarantees that
+the underlying memory system provides for load and store operations.}.
+Sequential consistency only requires that there exists a sequential
+history that is consistent with the {\it program order} (the intra-thread
+order).  This ordering does not need to be consistent with the order
+that the operations were actually issued in.
+
+Line-Up~\cite{lineup}, Paraglider~\cite{VechevMCLinear}, and
+VYRD~\cite{vyrd} leverage linearizability to test concurrent data
+structures.  {\bf Unfortunately, efficient implementations of many
+common data structures, e.g., RCU~\cite{rcu}, MS
+Queue~\cite{lockfreequeue}, etc., for the C/C++ memory model are
+neither linearizable nor sequentially consistent! Thus previous tools
+cannot check such data structures under the C/C++ memory model.}
+
+\mysubsection{New Challenges from the C/C++ Memory Model}
+\label{sec:introNewChallenges}
+
+The C/C++ memory model brings the following two key challenges that prevent the application of previous approaches to specifying the concurrent data structures to this setting:
+
+\squishcount
+\item {\bf Relaxed Executions Break Existing Data Structure Consistency Models:}
+C/C++ data structures often expose clients to weaker (non-SC)
+behaviors to gain performance.  A common guarantee is to provide
+happens-before synchronization between operations that implement
+updates and the operations that read those updates.  These data
+structures often do not guarantee that different threads observe updates in the
+same order --- in other words the data structures may expose clients
+to weaker consistency models than sequential consistency.  For
+example, even when one uses the relatively strong \code{acquire}
+and \code{release} memory orderings in C++, it is possible for two
+different threads to observe two stores happening in
+different orders, i.e., executions can fail the IRIW test.
+Thus many data structures legitimately admit executions for which there
+are no sequential histories that preserve program order.
+
+Like many other relaxed memory models, the C/C++ memory model does
+not include a total order over all memory operations, thus even
+further complicating the application of traditional approaches to correctness,
+e.g., linearization cannot be applied.  In
+particular the approaches that relate the behaviors of concurrent data
+structures to analogous sequential data structures break down due to
+the absence of a total ordering of the memory operations.  While many
+of the dynamic tools~\cite{cdschecker,relacy} for exploring the
+behavior of code under relaxed models do as a practical matter
+print out an execution in some order, this order is to some degree arbitrary as relaxed memory models
+generally make it possible for a data structure operation to see the
+effects of operations that appear later in any such an order (e.g., a load
+can read from a store that appears later in the order).  Instead of a total order, the C/C++
+memory model is formulated as a graph of memory operations
+with several partial orders defined in this graph.
+
+\item {\bf Constraining Reorderings (Specifying Synchronization Properties):}
+Synchronization\footnote{Synchronization here is not mutual exclusion,
+  but rather a lower-level property that captures which stores must be
+  visible to a thread.  In other words, it constrains which
+  reorderings can be performed by a processor or compiler.} in C/C++
+  provides an ordering between memory operations to different
+  locations.  Concurrent data structures must establish
+  synchronization or they potentially expose their users to highly
+  non-intuitive behavior that is likely to break client code.  For
+  example, consider the case of a concurrent queue that does not
+  establish synchronization between enqueue and dequeue operations. Consider the
+  following sequence of operations: (1) thread A initializes the fields of a new
+  object X; (2) thread A enqueues the reference to X in such a queue
+  (3) thread B dequeues the reference to X; (4) thread B reads the
+  fields of X through the dequeued reference. In (4), thread B could fail to see the
+  initializing writes from (1).
+  This surprising behavior could occur if the compiler or CPU could
+  reorder the initializing writes to be executed after the enqueue
+  operation.  If the fields are non-atomic, such loads are considered
+  data races and violate the data race free requirement of the C/C++
+  language standard and thus the program has no semantics.
+
+The C/C++ memory model formalizes synchronization in terms of a {\it
+  happens-before} relation.  The C/C++ happens-before relationship
+is a partial order over memory accesses.  If memory access {\it x}
+happens before memory access {\it y}, it means that the effects of
+{\it x} must be ordered before  the effects of {\it y}. 
+\countend
+
+\begin{figure}
+        \centering
+\vspace{-.3cm}
+       \includegraphics[scale=0.35]{figures/specworkflow}
+\vspace{-.4cm}
+               \caption{\label{fig:specworkflow} \TOOL system overview}
+\vspace{-.4cm}
+\end{figure}
+
+\mysubsection{Specification Language and Tool Support}
+
+Figure~\ref{fig:specworkflow} presents an overview of the \TOOL system. After
+implementing a concurrent data structure, developers annotate their code
+with a \TOOL specification. To test their implementation,
+developers compile the data structure with the \TOOL specification
+compiler to extract the specification and generate a program that is instrumented with specification checks.
+ Then, developers compile the instrumented program with a
+standard C/C++ compiler. Finally, developers run the binary under 
+the \TOOL checker. \TOOL
+then exhaustively explores the behaviors of the specific unit test and
+generates diagnostic reports for any executions that violate the specification.
+
+\mysubsection{Contributions}
+
+This paper makes the following contributions:
+
+\squishlist
+\item {\bf Specification Language:} It introduces a specification
+  language that enables developers to write specifications of
+  concurrent data structures developed for a relaxed memory model in a
+  simple fashion that capture the key correctness properties.  Our
+  specification language is the first to our knowledge that supports concurrent data
+  structures that use C/C++ atomic operations.
+
+\item {\bf A Technique to Relate Concurrent Executions to Sequential Executions:}  It presents an approach to order the memory operations for the
+  C/C++ model, which lacks a definition of a trace and for which one
+  generally cannot even construct a total order of atomic operations
+  that is consistent with the program order.  The generated
+  sequential execution by necessity does not always maintain program order.
+  
+\item {\bf Synchronization Properties:} It presents (a) constructs
+  for specifying the happens before relations that a data structure
+  should establish, and (b) tool support for checking these properties and
+  exposing synchronization related bugs.
+
+\item {\bf Tool for Checking C/C++ Data Structures Against Specifications:}
+\TOOL is the first tool to our knowledge that can check concurrent data
+structures that exhibit relaxed behaviors against specifications that are
+specified in terms of intuitive sequential executions.
+
+\item {\bf Evaluation:} It shows that the \TOOL specification language can express key correctness properties for a
+set of real-world concurrent data structures, that our tool can detect
+  bugs, and that our tool can unit test real world data structures
+  with reasonable performance.
+\squishend
+
diff --git a/correctness-model/writeup/issta15_submission.pdf b/correctness-model/writeup/issta15_submission.pdf
new file mode 100644 (file)
index 0000000..84e6eed
Binary files /dev/null and b/correctness-model/writeup/issta15_submission.pdf differ
diff --git a/correctness-model/writeup/makefile b/correctness-model/writeup/makefile
new file mode 100644 (file)
index 0000000..6c222e4
--- /dev/null
@@ -0,0 +1,94 @@
+LATEX := pdflatex -halt-on-error
+
+FIGURES = 
+
+#FIGHEAD = #figures/figHeader.dotpiece
+#FIGFOOT = #figures/figFooter.dotpiece
+
+
+.SUFFIXES : .tex .bbl .aux .eps .ps .dot .pdf
+
+.tex.bbl:
+       bibtex $*
+
+.tex.aux:
+       latex $*
+
+%.eps: %.ps
+       ps2epsi $< $@
+
+%.ps: %.dot
+       dot -Tps $< -o $@
+
+%.pdf: %.dot
+       dot -Tpdf $< -o $@
+
+%.png: %.dot
+       dot -Tpng $< -o $@
+
+%.aux: %.tex
+       $(LATEX) $<
+
+#%.dot: %.dotpiece $(FIGHEAD) $(FIGFOOT)
+#      cat $(FIGHEAD) $< $(FIGFOOT) > $@
+
+
+
+# latex the paper (default)
+new:   biblinks newpaper
+
+# latex + bibtex the paper
+bib:   bibpaper newpaper
+
+# save a backup of tex files in BACKUPS
+bak:   backuppaper
+
+
+biblinks: figures
+       $(LATEX) paper.tex
+       bibtex paper.aux
+       $(LATEX) paper.tex
+
+
+newpaper: figures biblinks
+       $(LATEX) paper.tex
+
+
+bibpaper: paper.aux paper.bbl
+       latex paper.tex
+
+
+backuppaper: 
+       @if [ ! -d BACKUPS ]; then mkdir BACKUPS; fi;   \
+       crtdate=`date '+%m-%d-%y--%H:%M:%S'`;           \
+       bakdir=BACKUPS/$$crtdate;                       \
+       mkdir $$bakdir;                                 \
+       cp *.tex $$bakdir
+
+spell:
+       @for i in *.tex; \
+       do if [ $$i != "paper.tex" ]; then aspell -c $$i -p ./spell.lst; fi;\
+       done
+
+
+total:
+       latex paper.tex
+       bibtex paper.aux
+       latex paper.tex
+       latex paper.tex
+       pdflatex paper.tex
+
+
+figures: $(FIGURES)
+
+
+errinjfig:
+       gnuplot err-inj-fig/nve2latex.cmds
+       epstopdf injectErrorFig.eps
+       mv injectErrorFig.* figures
+
+
+clean:
+       rm -f *.dvi *.log *.aux *.blg *.bbl *~ err-inj-fig/*~
+       rm -f paper.ps paper.pdf 
+       rm -f injectErrorFig*
diff --git a/correctness-model/writeup/memorymodel.tex b/correctness-model/writeup/memorymodel.tex
new file mode 100644 (file)
index 0000000..73e2e8e
--- /dev/null
@@ -0,0 +1,102 @@
+\section{C/C++ Memory Model}\label{sec:memorymodel}
+
+We next briefly summarize the key aspects of the C/C++ memory model.  The
+memory model describes a set of atomic operations and the
+corresponding allowed behaviors of programs that utilize them.  A more
+detailed formal treatment of the memory model~\cite{c11popl} and a
+more detailed informal description~\cite{cpp11spec,c11spec} are
+available in the literature.  Any operation on an atomic object will
+have one of six \textit{memory orders}, each of which falls into one
+or more of the following categories.
+
+\begin{description}
+
+       \item[relaxed:]
+               \code{\small{memory\_order\_relaxed}} --
+               weakest ordering
+
+       \item[release:]
+               \code{\small{memory\_order\_release}},
+               \code{\small{memory\_order\_acq\_rel}}, and
+               \code{\small{memory\_order\_seq\_cst}} --
+               a store-release may form release/consume or release/acquire synchronization
+
+       \item[consume:\footnotemark{}]
+               \code{\small{memory\_order\_consume}} --
+               a load-consume may form release/consume synchronization
+
+               \footnotetext{Consume is not broadly supported by compilers due to
+      challenges associate with preserving data dependencies and is
+      unlikely to provide significant performance gains on x86
+      hardware. We take the same approach as many compilers and treat
+      consumes as acquires.}
+    
+       \item[acquire:]
+               \code{\small{memory\_order\_acquire}},
+               \code{\small{memory\_order\_acq\_rel}}, and
+               \code{\small{memory\_order\_seq\_cst}} --
+               a load-acquire may form release/acquire synchronization
+
+       \item[seq-cst:]
+               \code{\small{memory\_order\_seq\_cst}} --
+               strongest ordering
+
+\end{description}
+
+\subsection{Relations}\label{sec:model-relations}
+
+The C/C++ memory model expresses program behavior in the form
+of binary relations or orderings. The following subsections will briefly
+summarize the relevant relations. Much of this discussion resembles the preferred model from the 
+formalization in \cite{c11popl}.
+
+\mypara{\bf Sequenced-Before:}
+The order of program operations within a single thread of execution establishes an intra-thread
+\textit{sequenced-before} (\reltext{sb}) relation.
+Note that while some operations in C/C++ provide no
+intra-thread ordering---the equality operator (\code{==}), for example---we
+ignore this detail and assume that \reltext{sb} totally orders all operations in
+a thread.
+
+\mypara{\bf Reads-From:}
+The \textit{reads-from} (\reltext{rf}) relation consists of store-load pairs $(X, Y)$
+such that $Y$ reads its value from the effect of $X$---or $X \relation{rf} Y$. In the
+C/C++ memory model, this relation is non-trivial, as a given load operation may
+read from one of many potential stores in the program execution.
+
+\mypara{\bf Synchronizes-With:}
+The \textit{synchronizes-with} (\reltext{sw}) relation captures
+synchronization that occurs when certain atomic operations interact across two
+threads. For instance, release/acquire synchronization occurs between a pair of
+atomic operations on the same object: a store-release $X$ and a load-acquire
+$Y$. If $Y$ reads from $X$, then $X$ synchronizes with $Y$---or $X
+\relation{sw} Y$.
+
+\mypara{\bf Happens-Before:}
+In \TOOL, we avoid consume operations, and so the \textit{happens-before}
+(\reltext{hb}) relation is simply the transitive closure of \reltext{sb} and
+\reltext{sw}.
+
+The \reltext{hb} relation restricts the stores that loads can read
+from.  For example, if we have two stores $X$ and $Y$ and
+a load $Z$ to the same memory location and $X \relation{hb} Y
+\relation{hb} Z$, then $Z$ cannot read from $X$.
+
+\mypara{\bf Sequential Consistency:}
+All seq-cst operations in a program execution form a
+total ordering (\reltext{sc}) so that, for instance, a seq-cst load may not read
+from a seq-cst store prior to the most recent store (to the same location) in
+the \reltext{sc} ordering, nor from any store that happens before that store.
+The \reltext{sc} order must be consistent with \reltext{hb}.
+
+\mypara{\bf Modification Order:}
+Each atomic object in a program execution has an associated \textit{modification order}
+(\reltext{mo})---a total order of all stores to that object---which
+informally represents a memory-coherent ordering in which those stores may be observed by
+the rest of the program.
+In general the modification orders for all objects cannot be combined
+to form a consistent total ordering.
+
+
+
+
diff --git a/correctness-model/writeup/paper.aux b/correctness-model/writeup/paper.aux
new file mode 100644 (file)
index 0000000..605a7ee
--- /dev/null
@@ -0,0 +1,75 @@
+\relax 
+\providecommand\hyper@newdestlabel[2]{}
+\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument}
+\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined
+\global\let\oldcontentsline\contentsline
+\gdef\contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}}
+\global\let\oldnewlabel\newlabel
+\gdef\newlabel#1#2{\newlabelxx{#1}#2}
+\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
+\AtEndDocument{\ifx\hyper@anchor\@undefined
+\let\contentsline\oldcontentsline
+\let\newlabel\oldnewlabel
+\fi}
+\fi}
+\global\let\hyper@last\relax 
+\gdef\HyperFirstAtBeginDocument#1{#1}
+\providecommand\HyField@AuxAddToFields[1]{}
+\providecommand\HyField@AuxAddToCoFields[2]{}
+\citation{rcu}
+\citation{lockfreequeue}
+\citation{javaConcurrentHashMap}
+\citation{cpp11spec}
+\citation{c11spec}
+\citation{boehmpldi}
+\citation{scmemorymodel}
+\citation{cdschecker}
+\citation{c11popl}
+\citation{relacy}
+\citation{linearizableref}
+\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{\thepage }{section.1}}
+\newlabel{sec:introduction}{{1}{\thepage }{Introduction}{section.1}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Background on Specifying the Correctness of Concurrent Data Structures}{\thepage }{subsection.1.1}}
+\citation{lineup}
+\citation{VechevMCLinear}
+\citation{vyrd}
+\citation{rcu}
+\citation{lockfreequeue}
+\citation{cdschecker}
+\citation{relacy}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}New Challenges from the C/C++ Memory Model}{\thepage }{subsection.1.2}}
+\newlabel{sec:introNewChallenges}{{1.2}{\thepage }{New Challenges from the C/C++ Memory Model}{subsection.1.2}{}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces  \textsc  {CDSSpec}\xspace  system overview}}{\thepage }{figure.1}}
+\newlabel{fig:specworkflow}{{1}{\thepage }{\TOOL system overview}{figure.1}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Specification Language and Tool Support}{\thepage }{subsection.1.3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}Contributions}{\thepage }{subsection.1.4}}
+\bibstyle{abbrv}
+\bibdata{confstrs-long,paper}
+\bibcite{cpp11spec}{1}
+\bibcite{c11spec}{2}
+\bibcite{c11popl}{3}
+\bibcite{boehmpldi}{4}
+\bibcite{lineup}{5}
+\bibcite{rcu}{6}
+\bibcite{vyrd}{7}
+\bibcite{linearizableref}{8}
+\bibcite{scmemorymodel}{9}
+\bibcite{javaConcurrentHashMap}{10}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Formalization of Correctness Model}{\thepage }{section.2}}
+\newlabel{sec:formalization}{{2}{\thepage }{Formalization of Correctness Model}{section.2}{}}
+\newlabel{line:startWithRelaxed}{{4}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\newlabel{line:setOfCandidates}{{7}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\newlabel{line:findSCViolation}{{11}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\newlabel{line:callStrengthenParam}{{13}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\newlabel{line:weakenOrderParams}{{15}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\newlabel{line:tmpOutputAsInput}{{18}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\newlabel{line:finalResults}{{20}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\newlabel{line:strengthenParam}{{24}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\newlabel{line:possibleFixes}{{25}{\thepage }{Formalization of Correctness Model}{Item.9}{}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Algorithm for inferring order parameters}}{\thepage }{figure.2}}
+\newlabel{fig:algorithmfence}{{2}{\thepage }{Algorithm for inferring order parameters}{figure.2}{}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}References}{\thepage }{section.3}}
+\bibcite{lockfreequeue}{11}
+\bibcite{cdschecker}{12}
+\bibcite{VechevMCLinear}{13}
+\bibcite{relacy}{14}
diff --git a/correctness-model/writeup/paper.bbl b/correctness-model/writeup/paper.bbl
new file mode 100644 (file)
index 0000000..e7f99db
--- /dev/null
@@ -0,0 +1,84 @@
+\begin{thebibliography}{10}
+
+\bibitem{cpp11spec}
+{ISO/IEC 14882:2011}, {Information} technology -- programming languages --
+  {C++}.
+
+\bibitem{c11spec}
+{ISO/IEC 9899:2011}, {Information} technology -- programming languages -- {C}.
+
+\bibitem{c11popl}
+M.~Batty, S.~Owens, S.~Sarkar, P.~Sewell, and T.~Weber.
+\newblock Mathematizing {C++} concurrency.
+\newblock In {\em Proceedings of the Symposium on Principles of Programming
+  Languages}, 2011.
+
+\bibitem{boehmpldi}
+H.~J. Boehm and S.~V. Adve.
+\newblock Foundations of the {C++} concurrency memory model.
+\newblock In {\em Proceedings of the 2008 ACM SIGPLAN Conference on Programming
+  Language Design and Implementation}, 2008.
+
+\bibitem{lineup}
+S.~Burckhardt, C.~Dern, M.~Musuvathi, and R.~Tan.
+\newblock Line-up: A complete and automatic linearizability checker.
+\newblock In {\em Proceedings of the 2010 ACM SIGPLAN Conference on Programming
+  Language Design and Implementation}, 2010.
+
+\bibitem{rcu}
+M.~Desnoyers, P.~E. McKenney, A.~S. Stern, M.~R. Dagenais, and J.~Walpole.
+\newblock User-level implementations of read-copy update.
+\newblock {\em IEEE Transactions on Parallel and Distributed Systems}, 2011.
+
+\bibitem{vyrd}
+T.~Elmas, S.~Tasiran, and S.~Qadeer.
+\newblock {VYRD}: Verifying concurrent programs by runtime refinement-violation
+  detection.
+\newblock In {\em Proceedings of the 2005 ACM SIGPLAN Conference on Programming
+  Language Design and Implementation}, 2005.
+
+\bibitem{linearizableref}
+M.~Herlihy and J.~Wing.
+\newblock Linearizability: a correctness condition for concurrent objects.
+\newblock {\em ACM Transactions on Programming Languages and Systems},
+  12(3):463--492, July 1990.
+
+\bibitem{scmemorymodel}
+L.~Lamport.
+\newblock How to make a multiprocessor computer that correctly executes
+  multiprocess programs.
+\newblock {\em IEEE Transactions on Computers}, 28(9):690--691, Sept. 1979.
+
+\bibitem{javaConcurrentHashMap}
+D.~Lea.
+\newblock util.concurrent.{ConcurrentHashMap} in java.util.concurrent the {Java
+  Concurrency Package}.
+\newblock
+  \url{http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html}.
+
+\bibitem{lockfreequeue}
+M.~M. Michael and M.~L. Scott.
+\newblock Simple, fast, and practical non-blocking and blocking concurrent
+  queue algorithms.
+\newblock In {\em Proceedings of the Fifteenth Annual ACM Symposium on
+  Principles of Distributed Computing}, 1996.
+
+\bibitem{cdschecker}
+B.~Norris and B.~Demsky.
+\newblock {CDSChecker}: Checking concurrent data structures written with
+  {C/C++} atomics.
+\newblock In {\em Proceeding of the 28th ACM SIGPLAN Conference on
+  Object-Oriented Programming, Systems, Languages, and Applications}, 2013.
+
+\bibitem{VechevMCLinear}
+M.~Vechev, E.~Yahav, and G.~Yorsh.
+\newblock Experience with model checking linearizability.
+\newblock In {\em International SPIN Workshop on Model Checking Software},
+  2009.
+
+\bibitem{relacy}
+D.~Vyukov.
+\newblock Relacy race detector.
+\newblock \url{http://relacy.sourceforge.net/}, 2011 Oct.
+
+\end{thebibliography}
diff --git a/correctness-model/writeup/paper.bib b/correctness-model/writeup/paper.bib
new file mode 100644 (file)
index 0000000..318493c
--- /dev/null
@@ -0,0 +1,774 @@
+@inproceedings{clockvector,
+    author = "Friedemann Mattern",
+    title = "Virtual Time and Global States of Distributed Systems",
+    booktitle = "Workshop on Parallel and Distributed Algorithms",
+    year = "1989"
+}
+
+@article{scmemorymodel,
+ author = {Lamport, Leslie},
+ title = { How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs},
+ journal = {IEEE Transactions on Computers},
+ issue_date = {September 1979},
+ volume = {28},
+ number = {9},
+ month = sep,
+ year = {1979},
+ pages = {690--691}
+} 
+
+@article{cantin,
+ author = {Cantin, Jason F. and Lipasti, Mikko H. and Smith, James E.},
+ title = {The Complexity of Verifying Memory Coherence and Consistency},
+ journal = {IEEE Transactions on Parallel and Distributed Systems},
+ issue_date = {July 2005},
+ volume = {16},
+ number = {7},
+ month = jul,
+ year = {2005},
+ issn = {1045-9219},
+ pages = {663--671}
+} 
+
+@inproceedings{roycav,
+ author = {Roy, Amitabha and Zeisset, Stephan and Fleckenstein, Charles J. and Huang, John C.},
+ title = {Fast and Generalized Polynomial Time Memory Consistency Verification},
+ booktitle = {Proceedings of the 18th International Conference on Computer Aided Verification},
+ year = {2006}
+} 
+
+
+@INPROCEEDINGS{qbornotqb,
+    author = {Ganesh Gopalakrishnan and Yue Yang and Hemanthkumar Sivaraj},
+    title = {{QB} or not {QB}: An efficient execution verification tool for memory orderings},
+    booktitle = cav04,
+    year = {2004},
+    pages = {401--413}
+}
+
+@Article{testsm,
+  author =       {Phillip B. Gibbons and Ephraim Korach},
+  title =        {Testing Shared Memories},
+  journal =      {SIAM Journal on Computing},
+  year =         {1997},
+  volume =    {26},
+  number =    {4},
+  pages =     {1208-1244},
+  month =     {August}
+}
+
+
+
+@inproceedings{koushiksc,
+ author = {Burnim, Jabob and Sen, Koushik and Stergiou, Christos},
+ title = {Sound and complete monitoring of sequential consistency for relaxed memory models},
+ booktitle = tacas11,
+ year = {2011}
+} 
+
+@inproceedings{burckhardtverif,
+ author = {Burckhardt, Sebastian and Musuvathi, Madanlal},
+ title = {Effective Program Verification for Relaxed Memory Models},
+ booktitle = cav08,
+ year = {2008}
+} 
+
+@inproceedings{checkfence,
+ author = {Burckhardt, Sebastian and Alur, Rajeev and Martin, Milo M. K.},
+ title = {CheckFence: Checking consistency of concurrent data types on relaxed memory models},
+ booktitle = pldi07,
+ year = {2007}
+}
+
+@inproceedings{cdschecker,
+ author = {Norris, Brian and Demsky, Brian},
+ title = {{CDSChecker}: Checking Concurrent Data Structures Written with {C/C++} Atomics},
+ booktitle = oopsla13,
+ year = {2013}
+}
+
+@inproceedings{poplabstraction,
+ author = {Batty, Mark and Dodds, Mike and Gotsman, Alexey},
+ title = {Library abstraction for {C/C++} concurrency},
+ booktitle = popl13,
+ year = {2013}
+} 
+
+
+@inproceedings{mspcboehm,
+ author = {Boehm, Hans},
+ title = {Can seqlocks get along with programming language memory models?},
+ booktitle = mspc12,
+ year = {2012},
+} 
+
+
+@inproceedings{pldisc,
+ author={Daniel Marino and Abhayendra Singh and Todd Millstein and Madanlal Musuvathi and Satish Narayanasamy},
+ title={A Case for an SC-Preserving Compiler},
+ booktitle=pldi11,
+ year={2011}
+}
+
+@inproceedings{ppoppworkstealing,
+ author = {L\^{e}, Nhat Minh and Pop, Antoniu and Cohen, Albert and Zappa Nardelli, Francesco},
+ title = {Correct and efficient work-stealing for weak memory models},
+ booktitle = ppopp13,
+ year = {2013}
+} 
+
+
+@inproceedings{adversarialmemory,
+ author = {Flanagan, Cormac and Freund, Stephen N.},
+ title = {Adversarial memory for detecting destructive races},
+ booktitle = pldi10,
+ year = {2010}
+} 
+
+
+@inproceedings{verisoft,
+ author = {Godefroid, Patrice},
+ title = {Model checking for programming languages using {VeriSoft}},
+ booktitle = popl97,
+ year = {1997}
+} 
+
+
+@ARTICLE{dillmodel,
+    author = {Seungjoon Park and David L. Dill},
+    title = {An Executable Specification and Verifier for Relaxed Memory Order},
+    journal = ieeetc,
+    year = {1999},
+    volume = {48}
+}
+
+@inproceedings{vechevpartialcoherence11,
+ author = {Kuperstein, Michael and Vechev, Martin and Yahav, Eran},
+ title = {Partial-coherence abstractions for relaxed memory models},
+ booktitle = pldi11,
+ year = {2011}
+} 
+
+@inproceedings{vechevfmcad,
+ author = {Kuperstein, Michael and Vechev, Martin and Yahav, Eran},
+ title = {Automatic inference of memory fences},
+ booktitle = fcad10,
+ year = {2010}
+}
+
+
+@article{sparcmodel,
+ author = {Jonsson, Bengt},
+ title = {State-space exploration for concurrent algorithms under weak memory orderings},
+ journal = {SIGARCH Computer Architecture News},
+ issue_date = {December 2008},
+ volume = {36},
+ number = {5},
+ month = jun,
+ year = {2009},
+ pages = {65--71},
+ numpages = {7},
+} 
+
+
+@inproceedings{inspect1,
+ author = {Yang, Yu and Chen, Xiaofang and Gopalakrishnan, Ganesh and Wang, Chao},
+ title = {Automatic Discovery of Transition Symmetry in Multithreaded Programs Using Dynamic Analysis},
+ booktitle = spin09,
+ year = {2009},
+ location = {Grenoble, France},
+ pages = {279--295}
+} 
+
+
+@article{sleepset,
+ author = {Godefroid, Patrice},
+ title = {Partial-Order Methods for the Verification of Concurrent Systems: An Approach to the State-Explosion Problem},
+ year = {1996},
+ journal = lncs,
+ vol = {1032}
+} 
+
+@Article{inspect2,
+  author =      {Chao Wang and Yu Yang and Aarti Gupta and Ganesh Gopalakrishnan},
+  title =       {Dynamic Model Checking with Property Driven Pruning to Detect Race Conditions},
+  journal =     {ATVA LNCS},
+  year={2008},
+  number =      {126--140}
+}
+
+
+
+@InProceedings{inspect3,
+  author =      {Yu Yang and Xiaofang Chen and Ganesh Gopalakrishnan and Robert M. Kirby},
+  title =       {Efficient Stateful Dynamic Partial Order Reduction},
+  booktitle = spin08,
+  year =        {2008}
+}
+
+
+@inproceedings{inspect4,
+ author = {Yang, Yu and Chen, Xiaofang and Gopalakrishnan, Ganesh and Kirby, Robert M.},
+ title = {Distributed Dynamic Partial Order Reduction Based Verification of Threaded Software},
+ booktitle = spin07,
+ year = {2007},
+ pages = {58--75}
+} 
+
+@Article{savage1997,
+ author = {Savage, Stefan and Burrows, Michael and Nelson, Greg and Sobalvarro, Patrick and Anderson, Thomas},
+ title = {Eraser: A Dynamic Data Race Detector for Multithreaded Programs},
+ journal = tocs,
+ volume = {15},
+ issue = {4},
+ month = {Nov.},
+ year = {1997},
+ pages = {391--411},
+}
+
+@inproceedings{Zhou2007,
+ author = {Zhou, Pin and Teodorescu, Radu and Zhou, Yuanyuan},
+ title = {{HARD}: Hardware-Assisted Lockset-based Race Detection},
+ booktitle = hpca07,
+ year = {2007},
+ pages = {121--132}
+} 
+
+@article{Gait1986,
+ author = {Gait, Jason},
+ title = {A probe effect in concurrent programs},
+ journal = {Software Practice and Experience},
+ volume = {16},
+ issue = {3},
+ month = {March},
+ year = {1986},
+ pages = {225--233}
+} 
+
+
+@inproceedings{Gupta2009,
+ author = {Gupta, Shantanu and Sultan, Florin and Cadambi, Srihari and Ivancic, Franjo and Rotteler, Martin},
+ title = {Using Hardware Transactional Memory for Data Race Detection},
+ booktitle = ipdps09,
+ year = {2009},
+ pages = {1--11},
+} 
+
+@inproceedings{Kudrjavets2006,
+ author = {Kudrjavets, Gunnar and Nagappan, Nachiappan and Ball, Thomas},
+ title = {Assessing the Relationship between Software Assertions and Faults: An Empirical Investigation},
+ booktitle = {Proceedings of the 17th International Symposium on Software Reliability Engineering},
+ year = {2006},
+ pages = {204--212}
+} 
+
+@inproceedings{lockfreequeue,
+ author = {Michael, Maged M. and Scott, Michael L.},
+ title = {Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms},
+ booktitle = podc96,
+ year = {1996}
+} 
+
+@inproceedings{testera,
+ author = {Marinov, Darko and Khurshid, Sarfraz},
+ title = {TestEra: A Novel Framework for Automated Testing of {Java} Programs},
+ booktitle = {Proceedings of the 16th IEEE International Conference on Automated Software Engineering},
+ year = {2001}
+} 
+
+@article{alloy,
+ author = {Jackson, Daniel},
+ title = {Alloy: A Lightweight Object Modelling Notation},
+ journal = {ACM Transactions on Software Engineering and Methodology (TOSEM)},
+ volume = {11},
+ issue = {2},
+ month = {April},
+ year = {2002},
+ pages = {256--290}
+} 
+
+
+@InProceedings{ltl,
+  author =      {Amir Pnueli},
+  title =       {The Temporal Logic of Programs},
+  booktitle = {Proceedings of the 18th Annual Symposium on Foundations of Computer Science (FOCS)},
+  pages =       {46--57},
+  Tyear =       {1977}
+}
+
+@inproceedings{boehmpldi,
+ author = {Boehm, Hans J. and Adve, Sarita V.},
+ title = {Foundations of the {C++} concurrency memory model},
+ booktitle = pldi08,
+ year = {2008}
+} 
+
+@Misc{cpp11spec,
+  title =       {{ISO/IEC 14882:2011}, {Information} Technology -- Programming Languages -- {C++}},
+}
+
+@Misc{c11spec,
+  title =       {{ISO/IEC 9899:2011}, {Information} Technology -- Programming Languages -- {C}},
+}
+
+@Misc{ieee1850,
+  title =       {1850-2005 {IEEE} Standard for Property Specification Language ({PSL})},
+}
+
+@Misc{c1xspec,
+  title =       {N1548: Programming languages -- {C}},
+  howpublished = {\url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf}},
+  month =       {December},
+  year =        {2010},
+}
+
+@InProceedings{fadinew1,
+  author =      {Lu, Shan and Park, Soyeon and Seo, Eunsoo and Zhou, Yuanyuan},
+  title =       {Learning from Mistakes -- A Comprehensive Study on Real World Concurrency Bug Characteristics},
+  booktitle = pldi08,
+  year =        {2008}
+}
+
+
+@Article{fadinew2,
+  author =      {Netzer, Robert H. B. and Miller, Barton P.},
+  title =       {What are Race Conditions?: Some Issues and Formalizations},
+  journal =     {ACM Letters on Programming Languages and Systems},
+  year =        {1992},
+  volume =      {1},
+  number =      {1},
+  pages =       {74--88},
+  month =       {March}
+}
+
+@InProceedings{fadinew3,
+  author =      {Jinpeng Wei and Carlton Pu},
+  title =       {Multiprocessors May Reduce System Dependability under File-based Race Condition Attacks},
+  booktitle = {Proceedings of the 37th Annual IEEE/IFIP International Conference on Dependable Systems and Networks},
+  year =        {2007}
+}
+
+@Article{rcu,
+  author =      {Mathie Desnoyers and Paul E McKenney and Alan S Stern and Michel R Dagenais and Jonathan Walpole},
+  title =       {User-Level  Implementations of Read-Copy Update},
+  journal =    tpds,
+  year =        {2011}
+}
+
+@InProceedings{crugiso,
+  author =      {Guoliang Jin and Aditya Thakur and Ben Liblit and
+                  Shan Lu},
+  title =       {Instrumentation and Sampling Strategies for
+                  {Cooperative} {Concurrency} {Bug} {Isolation}},
+  booktitle =   oopsla10,
+  year =        2010
+}
+
+@inproceedings{incrementalhashing,
+ author = {Nguyen, Viet Yen and Ruys, Theo C.},
+ title = {Incremental Hashing for {SPIN}},
+ booktitle = spin08,
+ year = {2008}
+} 
+
+@inproceedings{racetrack,
+ author = {Yu, Yuan and Rodeheffer, Tom and Chen, Wei},
+ title = {RaceTrack: Efficient Detection of Data Race Conditions via Adaptive Tracking},
+ booktitle = sosp05,
+ year = {2005}
+} 
+
+
+@inproceedings{nitpicking,
+ author = {Blanchette, Jasmin Christian and Weber, Tjark and Batty, Mark and Owens, Scott and Sarkar, Susmit},
+ title = {Nitpicking {C++} concurrency},
+ booktitle = ppdp11,
+ year = {2011}
+} 
+
+
+@inproceedings{c11popl,
+ author = {Batty, Mark and Owens, Scott and Sarkar, Susmit and Sewell, Peter and Weber, Tjark},
+ title = {Mathematizing {C++} Concurrency},
+ booktitle = popl11,
+ year = {2011}
+} 
+
+@inproceedings{fairstateless,
+ author = {Musuvathi, Madanlal and Qadeer, Shaz},
+ title = {Fair stateless model checking},
+ booktitle = pldi08,
+ year = {2008}
+} 
+
+@Misc{javaConcurrentHashMap,
+  author =      {Doug Lea},
+  title =       {util.concurrent.{ConcurrentHashMap} in java.util.concurrent the {Java Concurrency Package}},
+  howpublished = {\url{http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html}}
+}
+
+@Misc{clickhashtable,
+  author =      {Cliff Click},
+  title =       {A Lock-Free Hash Table},
+  howpublished = {\url{http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf}},
+  month =       {May},
+  year =        {2007}
+}
+
+@inproceedings{racerx,
+ author = {Engler, Dawson and Ashcraft, Ken},
+ title = {{RacerX}: Effective, Static Detection of Race Conditions and Deadlocks},
+ booktitle = sosp03,
+ year = {2003}
+} 
+
+@inproceedings{conflictexceptions,
+ author = {Lucia, Brandon and Ceze, Luis and Strauss, Karin and Qadeer, Shaz and Boehm, Hans},
+ title = {Conflict Exceptions: Simplifying Concurrent Language Semantics with Precise Hardware Exceptions for Data-Races},
+ booktitle = isca10,
+ year = {2010}
+} 
+
+
+@inproceedings{fasttrack,
+ author = {Flanagan, Cormac and Freund, Stephen N.},
+ title = {{FastTrack}: Efficient and Precise Dynamic Race Detection},
+ booktitle = pldi09,
+ year = {2009}
+} 
+
+
+@inproceedings{goldilocks,
+ author = {Elmas, Tayfun and Qadeer, Shaz and Tasiran, Serdar},
+ title = {Goldilocks: A Race and Transaction-Aware {Java} Runtime},
+ booktitle = pldi07,
+ year = {2007}
+} 
+
+@inproceedings{boyapati,
+ author = {Chandrasekhar Boyapati and Robert Lee and Martin Rinard},
+ title = {{Ownership Types for Safe Programming: Preventing Data Races and Deadlocks}},
+ booktitle = oopsla02,
+ year = {2002}
+ }
+
+
+@Misc{relacy,
+  author =      {Dmitriy Vyukov},
+  title =       {Relacy Race Detector},
+  howpublished = {\url{http://relacy.sourceforge.net/}},
+  month =       {2011},
+  year =        {Oct.}
+}
+
+@Book{spinmodel,
+  author =      {Gerard J. Holzmann},
+  title =       {The {SPIN} Model Checker: Primer and Reference Manual},
+  publisher =   {Addison-Wesley Professional},
+  year =        {2003},
+  edition =     {1st}
+}
+
+@Book{multiprocessorprogramming,
+  author =      {Maurice Herlihy and Nir Shavit},
+  title =       {The Art of Multiprocessor Programming},
+  publisher =   {Morgan Kaufmamn},
+  year =        {2012},
+  edition =     {Revised 1st}
+}
+
+@InProceedings{dpor,
+  author =      {Cormac Flanagan and Patrice Godefroid},
+  title =       {Dynamic Partial-Order Reduction for Model Checking Software},
+  booktitle = popl05,
+  month = {Jan.},
+  year =        {2005}
+}
+
+@Article{shavitcacm,
+  author =      {Nir Shavit},
+  title =       {Data Structures in the Multicore Age},
+  journal =     cacm,
+  year =        {2011},
+  volume =      {54},
+  number =      {3},
+  month =       {March}
+}
+%  pages =      {76--84},
+
+@inproceedings{chess,
+    author = {Madanlal Musuvathi and Shaz Qadeer and Piramanayagam Arumuga Nainar and Thomas Ball and Gerard Basler and Iulian Neamtiu},
+    title = {Finding and Reproducing {Heisenbugs} in Concurrent Programs},
+    year = {2008},
+    booktitle=osdi08
+}
+
+
+@inproceedings{lineup,
+ author = {Burckhardt, Sebastian and Dern, Chris and Musuvathi, Madanlal and Tan, Roy},
+ title = {Line-up: A Complete and Automatic Linearizability Checker},
+ booktitle = pldi10,
+ year = {2010}
+} 
+
+@inproceedings{berger-grace-09,
+  author = {Berger, Emery D. and Yang, Ting and Liu, Tongping and Novark, Gene},
+  title = {Grace: Safe multithreaded programming for {C}/{C}++},
+  booktitle = oopsla09,
+  year = {2009},
+}
+
+@INPROCEEDINGS{charisma,
+author = {Chao Huang and Laxmikant V. Kale},
+title = {Charisma: Orchestrating Migratable Parallel Objects},
+booktitle = hpdc07,
+year = {2007}  
+}
+
+
+@inproceedings{ding-bop-07,
+  author = {Ding, Chen and Shen, Xipeng and Kelsey, Kirk and Tice, Chris and Huang, Ruke and Zhang, Chengliang},
+  title = {Software behavior oriented parallelization},
+  booktitle = pldi07,
+  year = {2007},
+}
+
+@Misc{tilepro64,
+  key =         {tilera},
+  title =       {TILEPro64 Processor},
+  howpublished = {\url{http://tilera.com/products/processors/TILEPRO64}},
+  month =       {December},
+  year =        {2010}
+}
+
+@Misc{magnycour,
+  key =         {amd},
+  title =       {{AMD} {Opteron} 6000 Series Platform},
+  howpublished = {\url{http://www.amd.com/us/products/server/processors/6000-series-platform/pages/6000-series-platform.aspx}},
+  month =       {December},
+  year =        {2010}
+}
+
+@inproceedings{delaunay,
+ author = {Guibas, Leonidas J. and Knuth, Donald E. and Sharir, Micha},
+ title = {Randomized Incremental Construction of {Delaunay} and {Voronoi} Diagrams},
+ booktitle = {Proceedings of the Seventeenth International Colloquium on Automata, Languages and Programming},
+ year = {1990},
+ location = {Warwick University, England},
+ pages = {414--431},
+ numpages = {18},
+ publisher = {Springer-Verlag New York, Inc.},
+ address = {New York, NY, USA},
+} 
+
+@inproceedings{1000core,
+ author = {Borkar, Shekhar},
+ title = {Thousand Core Chips: A Technology Perspective},
+ booktitle = dac07,
+ year = {2007}
+ }
+
+@PhDThesis{r-cilk-98,
+  author = {Keith H. Randall},
+  title = {Cilk: Efficient Multithreaded Computing},
+  school = {Massachusetts Institute of Technology},
+  year = 1998,
+} 
+
+@InProceedings{dll-jcilk-05,
+  author = {John S. Danaher and I-Ting Angelina Lee and Charles E. Leiserson},
+  title = {The {JCilk} Language for Multithreaded Computing},
+  booktitle = scool05,
+  year = 2005,
+}
+
+@inproceedings{java-grande,
+  author = {Smith, L. A. and Bull, J. M. and Obdrz\'{a}lek, J.},
+  title = {A Parallel {J}ava {G}rande Benchmark Suite},
+  booktitle = sc01,
+  year = {2001}
+}
+
+@inproceedings{spin-commit-atomicity,
+ author = {Flanagan, Cormac},
+ title = {Verifying Commit-Atomicity using Model-Checking},
+ booktitle = spin04,
+ year = {2004}
+}
+
+@Article{linearizableref,
+       author =        {Maurice Herlihy and Jeannette Wing},
+       title = {Linearizability: a correctness condition for concurrent objects},
+       journal =       {ACM Transactions on Programming Languages and Systems},
+       year =  {1990},
+       volume =        {12},
+       number =        {3},
+       pages = {463-492},
+       month = {July}
+}
+
+@Article{refinement-mapping,
+  author =       {Abadi, Martine and Lamport, Leslie},
+  title =        {The existence of Refinement Mapping},
+  journal =      {Theoretical Computer Science},
+  year =         {1991},
+  volume =    {82},
+  number =    {2},
+  pages =     {253-284},
+  month =     {May}
+}
+
+@inproceedings{abstraction-linearizability,
+ author = {Amit, D. and Rinetzky, N. and Reps, T. and Sagiv, M. and Yahav, E. },
+ title = {Comparison under Abstraction for Verifying Linearizability},
+ booktitle = cav07,
+ year = {2007}
+}
+
+@inproceedings{formal-verification-set,
+ author = {Colvin, R. and Groves, L. and Luchangco, V. and Moir, M.},
+ title = {Formal Verification of a Lazy Concurrent List-Based Set Algorithm},
+ booktitle = cav06,
+ year = {2006}
+}
+
+@inproceedings{concurrit,
+ author = {Elmas, T. and Burnim, J. and Necula, G. and Sen, K.},
+ title = {{CONCURRIT}: A Domain Specific Language for Reproducing Concurrency Bugs},
+ booktitle = pldi13,
+ year = {2013}
+}
+
+@inproceedings{gambit,
+ author = {Coons, K. E. and Burckhardt, S. and Musuvathi, M.},
+ title = {{GAMBIT}: Effective Unit Testing for Concurrency Libraries},
+ booktitle = ppopp10,
+ year = {2010}
+}
+
+@inproceedings{memtest,
+ author = {Burnim, J. and Sen, K. and Stergiou, C.},
+ title = {Testing Concurrent Programs on Relaxed Memory Models},
+ booktitle = issta11,
+ year = {2011}
+}
+
+@inproceedings{ndetermin,
+ author = {Burnim, J. and Elmas, T. and Necula, G. and Sen, K.},
+ title = {{NDetermin}: Inferring Nondeterministic Sequential Specifications for Parallelism Correctness},
+ booktitle = ppopp12,
+ year = {2012}
+}
+
+@inproceedings{vyrd,
+ author = {Elmas, T. and Tasiran, S. and Qadeer, S.},
+ title = {{VYRD}: VerifYing Concurrent Programs by Runtime Refinement-Violation Detection},
+ booktitle = pldi05,
+ year = {2005}
+}
+
+@inproceedings{thread-quantification,
+ author = {Berdine, J. and Lev-Ami, T. and Manivich, R. and Ramalingam, G. and Sagiv, M.},
+ title = {Thread Quantification for Concurrent Shape Analysis},
+ booktitle = cav08,
+ year = {2008}
+}
+
+@inproceedings{VechevMCLinear,
+ author = {Vechev, Martin and Yahav, Eran and Yorsh, Greta},
+ title = {Experience with Model Checking Linearizability},
+ booktitle = "International SPIN Workshop on Model Checking Software",
+ year = {2009}
+}
+
+@inproceedings{shape-value-abstraction,
+ author = {Vafeiadis, Viktor},
+ title = {Shape-Value Abstraction for Verifying Linearizability},
+ booktitle = vmcai09, 
+ year = {2009}
+}
+
+@Article{test-verify-concurrent-objects,
+  author =       {Wing, Jeannette M. and Gong, Chun},
+  title =        {Testing and Verifying Concurrent Objects},
+  journal =      {Journal of Parallel and Distributed Computing - Special issue on parallel I/O systems},
+  year =         {1993},
+  volume =    {17},
+  number =    {1-2},
+  pages =     {164-182},
+  month =     {Jan./Feb.}
+}
+
+@inproceedings{stamp,
+    title     = {{STAMP}: Stanford Transactional Applications for Multi-Processing},
+    author    = {Cao Minh, Chi and Chung, JaeWoong and Kozyrakis, Christos and Olukotun, Kunle},
+    booktitle = iiswc08,
+    year      = {2008}
+}
+
+@article{l-clocks,
+  author = {Lamport, Leslie},
+  title = {Time, clocks, and the ordering of events in a distributed system},
+  journal = cacm,
+  issue_date = {July 1978},
+  volume = {21},
+  number = {7},
+  month = jul,
+  year = {1978},
+  pages = {558--565},
+  numpages = {8},
+  acmid = {359563},
+  publisher = {ACM},
+  address = {New York, NY, USA},
+  keywords = {clock synchronization, computer networks, distributed systems, multiprocess systems},
+} 
+
+@inproceedings{reverse-execution,
+  author = {Pan, Douglas Z. and Linton, Mark A.},
+  title = {Supporting reverse execution for parallel programs},
+  booktitle = padd88,
+  year = {1988}
+}
+
+@misc{linux,
+  title = {Linux Kernel v3.6},
+  howpublished = {\url{http://kernel.org/}},
+  month = {September},
+  year = {2012},
+}
+
+@inproceedings{mcs-lock,
+  author = {Mellor-Crummey, John M. and Scott, Michael L.},
+  title = {Synchronization without contention},
+  booktitle = asplos91,
+  year = {1991},
+  location = {Santa Clara, California, United States},
+  pages = {269--278},
+  numpages = {10},
+  acmid = {106999},
+} 
+
+@misc{barrier-url,
+  howpublished = {\url{http://stackoverflow.com/questions/8115267/writing-a-spinning-thread-barrier-using-c11-atomics}},
+  note =       {Oct. 2012},
+}
+
+@misc{mcs-lock-url,
+  howpublished = {\url{http://cbloomrants.blogspot.com/2011/07/07-18-11-mcs-list-based-lock\_18.html}},
+  note =       {Oct. 2012},
+}
+
+@misc{spsc-queue-url,
+  howpublished = {\url{https://groups.google.com/forum/#!msg/comp.programming.threads/nSSFT9vKEe0/7eD3ioDg6nEJ}},
+  note =       {Oct. 2012},
+}
+
+@misc{mpmc-queue-url,
+  howpublished = {\url{http://cbloomrants.blogspot.com/2011/07/07-30-11-look-at-some-bounded-queues.html}},
+  note =       {Oct. 2012},
+}
+
+@misc{dekker-url,
+  howpublished = {\url{http://www.justsoftwaresolutions.co.uk/threading/}},
+  note =       {Dec. 2012},
+}
diff --git a/correctness-model/writeup/paper.blg b/correctness-model/writeup/paper.blg
new file mode 100644 (file)
index 0000000..6a4c408
--- /dev/null
@@ -0,0 +1,50 @@
+This is BibTeX, Version 0.99d (TeX Live 2013/Debian)
+Capacity: max_strings=35307, hash_size=35307, hash_prime=30011
+The top-level auxiliary file: paper.aux
+The style file: abbrv.bst
+Database file #1: confstrs-long.bib
+Database file #2: paper.bib
+Warning--to sort, need author or key in cpp11spec
+Warning--to sort, need author or key in c11spec
+You've used 14 entries,
+            2118 wiz_defined-function locations,
+            816 strings with 16605 characters,
+and the built_in function-call counts, 3810 in all, are:
+= -- 331
+> -- 190
+< -- 0
++ -- 76
+- -- 62
+* -- 224
+:= -- 631
+add.period$ -- 38
+call.type$ -- 14
+change.case$ -- 73
+chr.to.int$ -- 0
+cite$ -- 16
+duplicate$ -- 158
+empty$ -- 358
+format.name$ -- 62
+if$ -- 806
+int.to.chr$ -- 0
+int.to.str$ -- 14
+missing$ -- 10
+newline$ -- 69
+num.names$ -- 24
+pop$ -- 115
+preamble$ -- 1
+purify$ -- 59
+quote$ -- 0
+skip$ -- 108
+stack$ -- 0
+substring$ -- 116
+swap$ -- 21
+text.length$ -- 0
+text.prefix$ -- 0
+top$ -- 0
+type$ -- 56
+warning$ -- 2
+while$ -- 27
+width$ -- 16
+write$ -- 133
+(There were 2 warnings)
diff --git a/correctness-model/writeup/paper.log b/correctness-model/writeup/paper.log
new file mode 100644 (file)
index 0000000..7b65903
--- /dev/null
@@ -0,0 +1,661 @@
+This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian) (format=pdflatex 2014.3.31)  10 APR 2015 10:40
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**paper.tex
+(./paper.tex
+LaTeX2e <2011/06/27>
+Babel <3.9h> and hyphenation patterns for 78 languages loaded.
+(./sig-alternate.cls
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/epsfig.sty
+Package: epsfig 1999/02/16 v1.7a (e)psfig emulation (SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2009/02/05 v1.0o Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 1999/03/16 v1.09 sin cos tan (DPC)
+)
+(/etc/texmf/tex/latex/config/graphics.cfg
+File: graphics.cfg 2009/08/28 v1.8 graphics configuration of TeX Live
+)
+Package graphics Info: Driver file: pdftex.def on input line 91.
+
+(/usr/share/texlive/texmf-dist/tex/latex/pdftex-def/pdftex.def
+File: pdftex.def 2011/05/27 v0.06d Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2010/04/08 v1.3 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2011/11/09 v1.22 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count79
+))
+\Gin@req@height=\dimen102
+\Gin@req@width=\dimen103
+)
+\epsfxsize=\dimen104
+\epsfysize=\dimen105
+)
+(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
+Package: amssymb 2013/01/14 v3.01 AMS font symbols
+
+(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty
+Package: amsfonts 2013/01/14 v3.01 Basic AMSFonts support
+\@emptytoks=\toks15
+\symAMSa=\mathgroup4
+\symAMSb=\mathgroup5
+LaTeX Font Info:    Overwriting math alphabet `\mathfrak' in version `bold'
+(Font)                  U/euf/m/n --> U/euf/b/n on input line 106.
+))
+(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
+Package: amsmath 2013/01/14 v2.14 AMS math features
+\@mathmargin=\skip41
+
+For additional information on amsmath, use the `?' option.
+(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
+Package: amstext 2000/06/29 v2.01
+
+(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty
+File: amsgen.sty 1999/11/30 v2.0
+\@emptytoks=\toks16
+\ex@=\dimen106
+))
+(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty
+Package: amsbsy 1999/11/29 v1.2d
+\pmbraise@=\dimen107
+)
+(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty
+Package: amsopn 1999/12/14 v2.01 operator names
+)
+\inf@bad=\count80
+LaTeX Info: Redefining \frac on input line 210.
+\uproot@=\count81
+\leftroot@=\count82
+LaTeX Info: Redefining \overline on input line 306.
+\classnum@=\count83
+\DOTSCASE@=\count84
+LaTeX Info: Redefining \ldots on input line 378.
+LaTeX Info: Redefining \dots on input line 381.
+LaTeX Info: Redefining \cdots on input line 466.
+\Mathstrutbox@=\box26
+\strutbox@=\box27
+\big@size=\dimen108
+LaTeX Font Info:    Redeclaring font encoding OML on input line 566.
+LaTeX Font Info:    Redeclaring font encoding OMS on input line 567.
+\macc@depth=\count85
+\c@MaxMatrixCols=\count86
+\dotsspace@=\muskip10
+\c@parentequation=\count87
+\dspbrk@lvl=\count88
+\tag@help=\toks17
+\row@=\count89
+\column@=\count90
+\maxfields@=\count91
+\andhelp@=\toks18
+\eqnshift@=\dimen109
+\alignsep@=\dimen110
+\tagshift@=\dimen111
+\tagwidth@=\dimen112
+\totwidth@=\dimen113
+\lineht@=\dimen114
+\@envbody=\toks19
+\multlinegap=\skip42
+\multlinetaggap=\skip43
+\mathdisplay@stack=\toks20
+LaTeX Info: Redefining \[ on input line 2665.
+LaTeX Info: Redefining \] on input line 2666.
+)
+Document Class 'sig-alternate' <23rd. May '12>. Modified by G.K.M. Tobin/Gerry 
+Murray
+Based in part upon document Style `acmconf' <22 May 89>. Hacked 4/91 by
+shivers@cs.cmu.edu, 4/93 by theobald@cs.mcgill.ca
+Excerpts were taken from (Journal Style) 'esub2acm.cls'.
+****** Bugs/comments/suggestions/technicalities to Gerry Murray -- murray@hq.ac
+m.org ******
+Questions on the style, SIGS policies, etc. to Adrienne Griscti griscti@acm.org
+
+\footheight=\dimen115
+\@maxsep=\dimen116
+\@dblmaxsep=\dimen117
+\aucount=\count92
+\originalaucount=\count93
+\auwidth=\dimen118
+\auskip=\dimen119
+\auskipcount=\count94
+\auskip=\dimen120
+\allauboxes=\dimen121
+\addauthors=\toks21
+\addauflag=\count95
+\subtitletext=\toks22
+\savesection=\count96
+\sectioncntr=\count97
+\c@figure=\count98
+\c@table=\count99
+\titleboxnotes=\toks23
+\titleboxnoteflag=\count100
+Document Class: sig-alternate 2012/05/23 - V2.5 - based on acmproc.cls V1.3 <No
+v. 30 '99>
+(/usr/share/texlive/texmf-dist/tex/latex/base/latexsym.sty
+Package: latexsym 1998/08/17 v2.2e Standard LaTeX package (lasy symbols)
+\symlasy=\mathgroup6
+LaTeX Font Info:    Overwriting symbol font `lasy' in version `bold'
+(Font)                  U/lasy/m/n --> U/lasy/b/n on input line 47.
+)
+\@acmtitlebox=\box28
+\titlenotecount=\count101
+\tntoks=\toks24
+\tntokstwo=\toks25
+\tntoksthree=\toks26
+\tntoksfour=\toks27
+\tntoksfive=\toks28
+\catcount=\count102
+\copyrightnotice=\toks29
+\conf=\toks30
+\confinfo=\toks31
+\c@part=\count103
+\c@section=\count104
+\c@subsection=\count105
+\c@subsubsection=\count106
+\c@paragraph=\count107
+
+Using 'Abbrev' bibliography style
+LaTeX Info: Redefining \cite on input line 1211.
+\bibindent=\dimen122
+\colcntr=\count108
+\saveb@x=\box29
+\copyrtyr=\toks32
+\acmcopyr=\toks33
+\boilerplate=\toks34
+\copyrightetc=\toks35
+(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+Package: fontenc 2005/09/27 v1.99g Standard LaTeX package
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def
+File: t1enc.def 2005/09/27 v1.99g Standard LaTeX file
+LaTeX Font Info:    Redeclaring font encoding T1 on input line 43.
+)
+LaTeX Font Info:    Try loading font information for T1+aer on input line 100.
+
+(/usr/share/texlive/texmf-dist/tex/latex/ae/t1aer.fd
+File: t1aer.fd 1997/11/16 Font definitions for T1/aer.
+)))
+(/usr/share/texlive/texmf-dist/tex/latex/psnfss/times.sty
+Package: times 2005/04/12 PSNFSS-v9.2a (SPQR) 
+)
+(/usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+Package: helvet 2005/04/12 PSNFSS-v9.2a (WaS) 
+)
+(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+\Urlmuskip=\muskip11
+Package: url 2013/09/16  ver 3.4  Verb mode for urls, etc.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+\lst@mode=\count109
+\lst@gtempboxa=\box30
+\lst@token=\toks36
+\lst@length=\count110
+\lst@currlwidth=\dimen123
+\lst@column=\count111
+\lst@pos=\count112
+\lst@lostspace=\dimen124
+\lst@width=\dimen125
+\lst@newlines=\count113
+\lst@lineno=\count114
+\abovecaptionskip=\skip44
+\belowcaptionskip=\skip45
+\lst@maxwidth=\dimen126
+
+(/usr/share/texlive/texmf-dist/tex/latex/listings/lstmisc.sty
+File: lstmisc.sty 2013/08/26 1.5b (Carsten Heinz)
+\c@lstnumber=\count115
+\lst@skipnumbers=\count116
+\lst@framebox=\box31
+)
+(/usr/share/texlive/texmf-dist/tex/latex/listings/listings.cfg
+File: listings.cfg 2013/08/26 1.5b listings configuration
+))
+Package: listings 2013/08/26 1.5b (Carsten Heinz)
+
+(/usr/share/texlive/texmf-dist/tex/latex/enumitem/enumitem.sty
+Package: enumitem 2011/09/28 v3.5.2 Customized lists
+\labelindent=\skip46
+\enit@outerparindent=\dimen127
+\enit@toks=\toks37
+\enit@inbox=\box32
+\enitdp@description=\count117
+)
+(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+Package: hyperref 2012/11/06 v6.83m Hypertext links for LaTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
+Package: hobsub-hyperref 2012/05/28 v1.13 Bundle oberdiek, subset hyperref (HO)
+
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty
+Package: hobsub-generic 2012/05/28 v1.13 Bundle oberdiek, subset generic (HO)
+Package: hobsub 2012/05/28 v1.13 Construct package bundles (HO)
+Package hobsub Info: Skipping package `infwarerr' (already loaded).
+Package hobsub Info: Skipping package `ltxcmds' (already loaded).
+Package: ifluatex 2010/03/01 v1.3 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+Package: ifvtex 2010/03/01 v1.5 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+Package: intcalc 2007/09/27 v1.1 Expandable calculations with integers (HO)
+Package: ifpdf 2011/01/30 v2.3 Provides the ifpdf switch (HO)
+Package ifpdf Info: pdfTeX in PDF mode is detected.
+Package: etexcmds 2011/02/16 v1.5 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)