// File[][] sources = { srcLinuxRWLocks, srcMSQueue, srcRCU,
// srcDeque, srcMCSLock, srcSPSCQueue, srcMPMCQueue, srcHashtable };
- File[][] sources = {srcMSQueue,srcHashtable, srcDeque };
+ File[][] sources = {srcRCU };
// Compile all the benchmarks
for (int i = 0; i < sources.length; i++) {
CodeGenerator gen = new CodeGenerator(sources[i]);
+++ /dev/null
-\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.
-
+++ /dev/null
-\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}
-
+++ /dev/null
-\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}
-
+++ /dev/null
-\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$.
-
-
-
-
+++ /dev/null
-\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.
+++ /dev/null
-/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//
+++ /dev/null
-Papers/15/issta.cdsspec
+++ /dev/null
-:ext:peizhaoo@plrg.eecs.uci.edu:/home/cvs/Papers
+++ /dev/null
-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.
+++ /dev/null
-\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.
+++ /dev/null
-@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"}
+++ /dev/null
-@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"}
+++ /dev/null
-\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.
+++ /dev/null
-\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.
-
-
+++ /dev/null
-/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
+++ /dev/null
-Papers/15/issta.cdsspec/figures
+++ /dev/null
-:ext:peizhaoo@plrg.eecs.uci.edu:/home/cvs/Papers
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-%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
AQBIAAAAAQAB/+4ADkFkb2JlAGTAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoK
DBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8f
Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAeAEAAwER
AAIRAQMRAf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA
AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB
UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE
1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ
qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy
obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp
0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo
+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A9LXvmXQ7HXdN0G6u1i1b
WEnk021IYmVbVVeajAFRxVwaMRXelaHFVlz5v8p2qSPc63YQJC4ilaS6hQJI0ssARizCjGa2ljof
2kZeqmiqAs/zM/Lu8svrtv5m0trURpM8hvIE4RyOI0aQMyslXYL8QHxGnXFVSL8wvJc+oWGn2urQ
3dxqbBLJrXlcROxSWQL60IeJSUtpD8TD7OKrta/MDyPoi3/6V16xtZNMUPf27zxmeLlE06KYFJl5
vEhZFC8mH2QcVVW87eTUleF9e09Jo/W9SJ7qFXT6tH60/JSwZfSiPOSo+FdzQYqvsfOHlXUNQj0/
T9Xs7y9ki9dILeeOZvT4o4b4C1OSSKy1+0u4qK4qm0jrGjOxAVAWYkgAAb9Ttirxz8r/AM/L7zl5
qk0a40uygilmeKD6netdTwCG0SaRpl9JEkh9XnGLiNghbiqhh+8ZV7JirTuqIzsaKoJY+AGKsd0X
8xvJGs6KNbstXhXSyzILm652Y5R2/wBcb4bpYW2tgZq0/u/j+zvird7+Y3kCw1E6be+Y9Ntr5PVE
kEt1CjI0HH1Fkq1EZfUHwtQ/ccVXzfmD5EheSN/MOnGaKL13t0uoXm9P0xMGESMztWNg4oNwQR1x
VdD548qyWGoahNqC2FnpM62upTakkmniCV1jZBJ9cWAqHE6cW6NyFCcVUG/Mr8vklkjk8xafGsSR
u873MawfvnmjRROxETOXtJRwDchxNRiqtcef/IttFLLP5i0yKOBTJMzXkACqspgZj8ewEymP/WHH
riqO8v8AmDRvMWjWmtaLdJe6Xep6ltcpUBlBKnZgrKQwIIIqDscVTDFXYq7FXYq7FXYq7FXYq7FX
Yq7FXYq7FXYqwrzj+U3lvzZrUetajPdxahBAlravC8bRRxr64lH1eeOaCX10umjlEyOCoAAHxVVQ
up/kt5avbrUbiK9vrBtUv01S7+rNb1FxEVaMwySwSywcJPVcGF1blLJU0ICqpQP+ccPJR09tOm1D
VJrIxpEkLS268FQ2X2Wjt0f4o9KtozUn4VqKMzMVUVon5H2Og2DWuj61dxyQXLanpl7cpFcTxak9
pdWj3E7FVW4Qrd8/T4r8S1LHkcVVPPP5CeTfOd1e3Op3WowS39wbm5+qTRxqxNtb2vplWicMgFlE
4DVIcVB7Yqh3/wCcfPKbalcXy6rqy/WZ7y5ltGmt5bUvfxzRuDBNBLGyx/XJjGGBoXatQxGKofS/
yf8ALHknW7PVbfVtVuDcyNEVuHF1cGcW04WRJFVZFUJLcySKFartyHEA1lEkXIDiEdz12sDf4kMJ
z4RbPbfRbe5hWa31i9mhb7MkdyGU022IGZEdaCLEYfJYkSFg2FT/AA5/2tNQ/wCR/wDzbh/N/wBC
HyZUgPMHkj9L6DqWlfpe+i/SFrPa+o8nqqvrRtHyaP4OYHL7PIV8cv0vaPhZY5OCB4JA8q5G+fRB
CRaNpGmflj5YdNb8w6prEFwEg5XhadEdUYcbdArGFWX9lpCNuuV9udtQzS8Q44YhZ+gbm/5x5E+d
BpzZ44Y3JLvLX5C+QYfKUOmp9dl066exvQtz9VjuB9V5ssbvbwxNxlimeOVCSKM5HF3d218JcQB7
26E+KIPeiZvyH0KbVm1eTXtX/STTi7M6GwjX1xLb3HqiBLNYA7T2UMjt6dXK/FUVGSZJLqn/ADjn
5RsAmsaXc6qdQ05LZrOAPFcQ87K3itYJHtisXqmKOItxDqzcnA+0FwSNC2zFDilVge/l+Ps79k30
jynpM2manDfarqt9pOs3tpq7NcwWzyreWl2Ll3e5sofT9NzBDEY5BWNY+IIGy1DOKsgj8eVtOWRx
yMckZRI8v0iwkifkZ+Wum6DILXzPq0NnJLYCS5gu7eZ5G055XtICBBIJQrSikfE/3aUHw72RmJcj
axnGW4Nquif848eTOaapY3OuaZc26tFpi3MtuTAoooeOF4pQKwqsP7wciigsOfx5JkzH8sfIF75G
8tWPl5dWF/YWIlEYNuImb1ZWkqzc3+zzptSvXFWRX9jrE0/qWep/VUoB6LQJKtR3qSrb998VRF42
pR2oNlHFcXS0qkztCjD9r4lSUg+Hw4qt025vriJje2ZspVbjw9RJVYUHxKy70/1gD7YqusNT07UI
jLY3MV1Gp4s0Tq9D4Gh2PscVROKuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxVJ/MpMKabfjf
6nf25KnoRck2TE/6q3Rb6MzNHvxx/nQP+x9f+9pBRdxo9pLM1xHztbpqFri3bgzEdOY3ST/Zqc18
sQJsbHy/G/xa5YYk2Nj3j8b/ABWi11mP4Y7+OROzT2/KT6TFJCv/AAuDhmOvzH6iEcMx/F8x+oh5
/rf5vWumebn8sXy34kiuYLSXUbK0thArz/UwGLT3Mz8UbVLcNSGvxbVoTjwzPM/IfrteCZ5y+Q/X
ac+S9U8o+edIuL1LCeZQYo5RqojklKXNtDfQunF5kRJIbqNwqlaHYqCMB08DzHF790HTQP1Di9+/
4+DNsub3Yq7FWPeYIbrTW/SeiRM+p3MixPYKCYbpyNjLTaJlVa+t4CjcvhGVmG9hzMeoBjwZd49D
/FH3d4/on4UbXaUtlq9up1GJU1y2VUvgim3uInP8rI5cIf2WVyrDocjwxnzG/wBrjanQiJBNEHlI
dfcefvGxHUIto9XsAGic6lbD7UMnFbkD/IccEeng9D/lHGpx5eofb+Pxbi1OHL1D7f2/H5sb/MXz
b5s0/wAtwah5IsU1W/aeZLi3ltri4KJBZXNxwaKF4pEkeeCOEcujOBSpGWQmJCw2QmJCwk/lnzv+
aN15n0zStZ0JYbOSS4hv7yOxvIo2WGXUEFwk0kjxQLS0taRycmk9fkpouSZvUMVdiqFOlab9fXUP
qsQvlBUXIUCTidiCw3I+eKoW9uPMFte+pBbRX2nPxDRRt6VzF2ZhzPpyjvSqn54qmmKuxV2KuxV2
KuxV2KuxV2KuxV2KuxV2KuxV2KoTV9OTUtKvNPkcxpdwyQGRd2X1FK8hXutajLcGU45xmP4SD8lK
l5f1KTUtGtbuZQl0ycLyJdxHcxExzx/7CVGX6MnqsIx5DEfT084neJ+IooCYZjpS648teXLi7a8u
NKs5rt3Ej3ElvE0hdTEVYuVLFgbWGh/4rT+VaKqmk6Jo2j2zWukWFtp1s7tK8FpCkCGRqcnKxhQW
NBU4qjcVdirsVY1qPmLWW8m69rWkWYub60gvpNDtQrym5e2jYQgxpxdvVlTZVNSpFN8VSjyPYeb9
W0W6vvNlyYfMMepXyadcQWv1P6vaxTGGJEjcu0sEwi9X96zVDjf4VbIShfvcjBqTjsEcUDzieR/U
e4j7rDKLHV5RdLp2qItvqBBMLLX0LhRuWhY96fajPxL7r8RYz3o82eXTDh48Z4ode+P9b9EuR8js
u1C2mglOpWKFp1A+tW6/8fEajoO3qL+we/2TsaiE4kHijz6+f7e75OtyRIPFHn18/wBvd8kdbXEF
zbx3EDiSGZQ8bjoVYVBy2MgRY5NsZCQsciqYWTsVdirsVS/VtGh1ERSCWS1vbeptbyBuMkZalRQ1
V1ag5KwIOKqzXkNlDapqFzGJ5mSBZSPTWWcrWiqS1OXE0FfbFUVirsVdirsVdirsVdirsVdirsVd
irsVdirsVSOz/wBxvmS6sj8NrqoN7Z+AuEAS6jHYchwlUdSTIe2ZuT95hEv4oek+7+E/fHy9IR1T
zMJLsVdirsVdiqnc3ENtby3E7cIYUaSVzU0VBVjt4AYq61jto7aKO2RY7dVAhjjUKoWmwVRQAUxV
UxVQvrC0v7Zra7jEsLUNKkEMDVWVloysp3VlNQdxglEEUWzFmljlxRNH8fMd46vLPM/5o635U836
Zot5DLJoSThLzWbmFozLFIvEBXoEf0S3JnWnKlKDcthZNRKEgDy73r9B2Bi1mlnliQM3D6YRN0R5
cxxcgDy533HGgaP5w078xZYb69mu9DeC4urRl/dw83kXkrxoFj9QGQnpv1+VOHFljnokmFE+X9r5
vgw5YZ6JJhRPl8uV7vQs2jtXYq7FXYq7FVG9srS+tZbS7iWa2mXjLE4qCMVSvSl1TTrsaXcCS8sG
Umxvz8Toq/7puD4gfYk/aGx+L7SqdYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYqluv6ZNf2A+qsI9R
tHFzp0rEhVnjB4huO/B1LRyU6ozDMnS5hCXq+iW0vcf0jmPMBBCto+qQ6pp0V7Epj58llhf7cUsb
FJYnp+1HIrK3uMhqMJxTMT/aDuD8RuoKMylLsVdirsVUNQtFvbC5s2PFbmJ4WbrQSKVrSo8cVYZ5
28k6vqs+kz2kNlqg06yurT6tqLrCkdzObdodQg52mpRevB9XYJzhI+M9qhlUm89fln5z8xarqUY1
ZZ/LOqNYCTSp7q5hWJEntnv+KxIwfnFp6JEoKbzTNVa/Gqx3Q/yl/OSzuTe6r5ij1O4kitYbqNNW
1S19WK3lleSL1kjeSP1jMsvqLuhUxqBG5oqj/Lnkj8xPLfka98kC3fWZLqK1GnalLfyfo6142lvF
cRSSC4ttRjj9eGV0SCMrxdQKfEAkJjIxNjYsR1X8kvzcljsjq/mS0uZm0270e6mn1jUoVumvrdI4
YgiwcI0imjV2Vf8AejgOY+I0BIDKMJTugT1P62d/l5pF75f1+K8uTaSXOp2lvputVvI/rK3FpNqM
8l8yH7aXDSwqiA81D/EBwOQ8aF1Ycfx4XVi/exf/AJUx+daSae8nme31JNPMFxFFf6lqzE3P6Okt
p29ZOMyD6xNI6GN0Yq1GNFRRY2qkH5T/APOQi29pH/jaOKRWtzdTG+1CdlMQPMxh0VZOTcnKuOLC
TgaCGJsVZZ+T3kTzr5X8webLjzBKJLTVmsZrPjf3GogyxQtFOxluljm5fCtSy7jiBsuKvUcVdirs
VSvT7nVE1K4sL+MyJ8U9lfIlEaIt/dSU2WSPkB/lLv2bFU0xV2KuxV2KuxV2KuxV2KuxV2KuxV2K
uxVj1/8A7gdWfVl20jUGRdXH7ME4ASK89kKhY5j2AVtgrnNhi/f4/D/ykPp8xzMff1j8RuTFHJkO
a9LsVdirsVdiqWaKl/DLqFtdmSSOO5eSznkJblDP+941O/7t2ZAPADFUzxV2KuxVTuLeC5geC4jW
aCUFZInAZWU9QQdjgItlCZiQYmiElmW50eNkuFfUdCP2i4M09sv+WDyaaIeO7r35DcVkcPPeLmmM
NTttHJ3coy/RGX+xPSuoqLRtIkgSbTj9VjkUPFLYyenGwIqr8UPpP7clODwY/wAO3u/FOrnpREkU
YEd232frC4nWbPc01K3HYBYrkf8AEYpP+Ep74+uP9Ifb+o/Yx9cf6Q+R/UfsRdlf2t7EZbd+QU8X
Ugq6MOqujAMrDwIrlkJiQsNkMgkLDzi9/wCcgfKNjqmoWF3puqRJpzXiTXxitzAxsRe8+HGcyH1D
pVwqVQbr8XEHJM2deWvMFtr+l/pCCCa14z3NpNbXAQSxz2dw9tMjek8sZ4yRMKq5B8cVTTFXGtDT
Y9id8VSzQtSubqKa2vkEep2L+ldqoIRqiqSx1r8Ei7jw3HbFUzxV2KuxV2KuxV2KuxV2KuxV2Kux
V2KrZI45Y3ilQSRyAq6MAVZSKEEHqDhBINjmqQaZNJoV5Fol45bT524aHeOanZS31OVj1dFUmNj9
pNjVlLNn5ojPE5Y/WPrH+/Hkf4h0O/I0ByZDmvS7FXYq7FUv12/u9PsDewRCaO3dXvI6Eubcf3pj
oftqPip3pTviqOilimiSWJg8Uih43U1DKwqCD7jFV2KuxV2Kpb5l1+z8veXtS129SSS00u2lu7iO
EKZGSFC7BA7IvKg2qwxVjHkzWNU1jTLrX9N0ttNhN/e2z6JNPG/rC0uHt5J1aOscE7SRPVAzIxH2
t+eVmJG4+TmxzxyARy9OUuo8j3x+0dLHpZfpup2moQGW3Y1Rik0LgpLFINykiHdWFfu3GxGSjIFo
z4JYzUvgehHeD1/HVSv9PkaT69Y8Y9RRaAsSI5lG/pzUrUfytSq9tqgwnD+KP1ff7/xs4eTHvxR+
r7/I/jZA2nl/yhqMTXf6FsjLK0n1hZbWEyCVmmEyyfCatyup+W5r6jnfmayhMSFs8cxIWE007TNN
0yyisdNtIbGxgBENrbRrFEgJLEKiBVWpJOwybNE4q7FUFrOotpumzX3omdLejzIpowiDD1HGxqUS
rU70piqMR0kRXRgyOAysNwQdwRireKuxV2KuxV2KuxV2KuxV2KuxV2KuxVQv7C0v7OW0u4/UglFG
XcEEGqsrChVlYBlYbg7jfLMWWUJCUeYVJtK1HUdOvU0TW3MzPUaXq5UBbpQK+lNxAVLlQNxsJB8S
ftKmXnxQyR8XFt/Oj/N8x3w+2PI9DIMgzAS7FXYq7FUvudWjtNTtrGeIxw3alba6qOBmXf0T/KxX
dfHcdt1UwxV2KuxVRvLOzvbSazvYI7m0uEMc9vMiyRyIwoyujAqykdQcVdaWdnZw+jaQR28PN5PS
iRUXnK5kkbioA5O7szHuSTiqF1HSfXmW9tJfqmpRrxS5A5K6AkiOZKr6iVJ2qCKniVJyEoXuObk4
dRwjgkOLGend5xPQ/YeoLWnav687WV3F9U1ONeT2xPJXQGhkgei+oladgVqOQUnGM72PNObTcI44
nixnr3eUh0P2HoSgtS1TTdE1JL66uorex1AGO4aR1UCaJSUk3PdFKN7hBlOTJHHKyaEvv/G3ydXl
mMU7kaEufv7/AJbfJObS6t7y1hu7ZxJb3EaywyCoDI4DK2/iDl8ZCQBHIuRGQkARyKrkmTsVcyqy
lWAKkUIO4IOKoWwksED2FmVUaeEgaBaj0x6asi79uBGKorFXYq7FXYq7FXYq7FXYq7FXYq7FXYq7
FUPqGn2eoWctlexCa2mFJIzUdDUEEUKspAKsDUHcb5ZiyyxyEomiFSZNRvNAYW+syGfSSQttrTfa
jqdo72gHH/Jn+yej8WoXzDijn3xisnWHf5w/4nmP4bH0jkyHNel2KuxVTntre4QR3ESSoGVwrqGA
ZCGVqHurCoxVCjWLYasdLmVoLhkEls0lAk6gfH6RB3KftKd+/TfFUdirsVS3zLr9n5e8valr18sj
2el20t3cJCA0jJChdggYqpYgbVI+eKpH/wArR8q2+l3Ooaw82i/UruawvbW8j5zRXMFq16Y2+qm5
Q8rZPUQqx5VCj4yFxVK5/wA9vINtc3trdPew3VnfnTRAbOd3nkFz9T5wemrh0M6yIo+23pycVPHF
Ut8zfmF5e83XK+T/AC5qL2mvXaxz6Rq1xZ3UdtIT9Yr9Uugq0cpaS8ZB8DrUIXPILVmgZRoc3Zdk
6vFgzCeUGWPrEdfeDsR5d9MDm1PQND8l6t5Q8+NcJrHlv1LvSZbS1uZpnt5ObM8QaOPnB6kThpXK
xbgcwRmEdF4mPgnzHIs/a38pr8oy4SQZDcEUYyG3u3Fcj0eg+Xvzl8nRaba6bZRX18mn/o2wluor
YxRFbwWsNtcqLhoX9CRrxODcasAzKCtCc7FDhgI9wDpsMOGAj3ABlHmH8y/JXl3WY9G1jUGtdQli
juFj+r3MiCKVpFVmljjeJf8AeeVjyYUVGY/CpOWNiUWH55/lxc2tjPPe3GnPqFvb3cMF7Z3UTeld
AmNuYjaFlorksjlaI7V4oxCq0/nt+XDajpNhbXlxdSaverpsUkdpcLFDcuXVY7h5UjEb84+PA/GK
glePxYqzSDTRDq15frJUXcUEbQ0pRoTJV+Vd+SyKOn7OKozFXYq7FXYq7FXYq7FXYq7FXYq7FXYq
7FXYq0yq6lWAZWFGU7gg9jhBpUgGmaloR5aKn1vSur6MzBWhA/5YnYhVH/FLkJ/KyAUOd40M/wDe
+mf8/v8A64/3w37xJHJNNM1fT9TieSzl5tE3p3ELApLE9K8JY2AdGpvRh036ZjZsE8ZqQ58u4+48
ioKMylLsVUri0tbgxG4hSUwuJYS6huEi9HWvQjxxVA3uttYX6xXlq6WMvFYdQSskYkJpwmVRyj36
Mar4kYqmeKoPWNI07WdJvNJ1KH6xp+oQyW13ByZOcUqlHXkhVlqp6qQcVSWP8tfJa6XNpclg11ZT
38eqzJd3FzdM17CyMkxknkkkrWFajlRtwQQTVVLH/JL8spLiK6k0h5LyEMI7t7y9a4DNdNemQzGb
1DJ9ZkaT1C3Kp64qqj8o/J9vIlxpS3WlahBJFLZ30FxJO9sYROqJBFeG6t44wl7OojEXAczQA0IV
QUn5D/ltcz315qNjPf6pqgYarqT3dzBPdB+QcSC1e3iCvy+JERUO3w7Ciqin5V+VPL1/LdWemTSa
LcJaC8tIp7qeRZNPlhls5WSR5ZHS2+qosaRMoVfh9NwfhhKRHucrDihkFXw5PP6T8f4T79j3jqaX
P5ZeQfMNlp0+qQtrzW0FlHDqdxcyvLMLAS+hLI8TorvW6lLNT4ixr2pIG+TjzhKBMZCiEvtv+cff
yhtmdodApzWJGVru9dSsI4x/C0xGyVT3Qsp+FmBLFdD+Q35ZWzaW1hpstj+h7qC9s0hurkx+tbuW
UyRSSSRyEhijMy8uPw1oBirL7H6++uanLNzWzRbeC1RieDFFaSSRB7mYIT/k07YqmWKuxV2KuxV2
KuxV2KuxV2KuxV2KuxV2KuxVgv5o+UvOfmOLTovLOrPpLQ/WUvZlvLm1HCeH00ZY7ZOUskbHnHyk
VVI3V67Kr/yr8qedfL+mXo84a42t6pdTh45BNNLDHFwDlEWULxInklAp/usIO1MVZJqnl+yvplu1
Z7PU4l4Q6jbEJOq1rwNQyyJX9iRWXvSuZOHVSgOH6oH+E8v2HzFFBCEXVtZ0v4Nbt/rNsOmrWMbs
v/Pa2HqSx/6yF16klBtlpwY8u+I1L+bI/dLYH48J6DiW05tLy0vLdLm0njubaUVjniZXRh0qrKSD
mJPHKB4ZAgjoUquQV2KpfqttrDmKbS7tIZYuXK2nTnBKDTZitJEIpsyn5qcVVn1CK0sY7nVJIrIk
IJi0g9NZGoOIkYJX4tgaDFUSjq6h0IZWAKsDUEHoQcVbxV2KuxV2KsN8yeYvK/lzXLS2TWbTTtf1
eaKOHRJXLfXZLlzFG5gjDyR83Ur9YC8RT4+VKZWYVuHMhqRKIhlFxHI/xR93eP6J+BiyTTtXgvHe
3ZHtr6EVnspqCRQTQMKEq6Hs6kjt1BGSjO/e15tMYAS+qB5SHL9h8jv8FLXNWlso4oLSMXGqXhKW
Vua8SRTlJIR0jjBqx+jqRknHTMVpv174q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX
YqlF55ZsZbiS8s5JdL1CU8pLuyYIXbpyliYPBMabAyRsR2pmXj1kgBGQE4DpLp7j9UfgQilL675n
0/a9s49Vtx1utP8A3UwFK/FazORQeKTMx7JkvDwZPpkYHuluP9MB98QP6S7ovT/MWi38/wBWt7oC
8AJNlMrQXIVdixt5gkoX3K0yrLpMkBZHp7xvH/TCx9q2mOY6WnRHQo6hkYUZSKgg9iDiqG0/StO0
6N4rC3S2ikcyNFGOKciADRRsvToMVQ1gPMkVwIr82l1bUP8ApcPqQSAjpWFvVU18RIPlird/5g07
T5/SvBPEKA+v9XmeHft6qIyA+xOKo6W6toYhNNKkURpSR2Crv03OKro5YpQTG6uBsSpB/VirD9R8
teTNS89af5gl1Mfp219BbW0SeCjfVY71FHplTIarqMpajfsr4GqqaeZbXUL14baxsQbpB6kGrSSC
JLVjtVeJMrttugXiw2Y0yMogt2HUSx3XI8weR9/4sdFWHVLzTnS31wqUNEh1aNeMLk7BZl39Fyff
gx6EE8cjxEbS+bkHTxyjixc+sOo/q/zh/sh1BA4k5qK0rudwPlljguxV2KuxV2KuxV2KuxV2KuxV
2KuxV2KuxV2KuxV2KuxV2KuxV2KobUNM03UYPq+oWsN3BXl6U6LItfGjA75ZizTxm4ExPkaWku/w
3Jb76Xql5ZU39F5PrkJNdqrdCZ1XtxjdMyPzYl9cIy+HCf8AY0PmCim+fm+3qGisNRXqZEeWyb/V
EbC7Vj7mRca08us4fKX2+n7iu7h5jkiI+u6RqFop2D+kl0CflZPcuP8AZKMfygP0zhL48P8AuxFb
bHnDyyu1xqEVk/8Avq9rZyf8i7gRP28MH5DN0iZf1fUPnG1sJhZ6lp18nOyuobpOvKGRZBTp1UnK
MmGcNpAx94pNqk9tb3EZiuIkmjO5SRQy/ca5Wqyz0+wskaOztorZGPJkhRYwT0qQoGKqdoukx3M0
FoIEuYqG4ii4B157rzVdxyptXJGEgASNiqA0/wA5eXb+LVbiC6aO00SWaHUr25hmtbaN7VnS443E
6RxSLE0Th2RmVabnIqo3XnvyMmoPpF3rVjHcuFQwTyoqOZZprX0lZyI3k9a1mjaMEsCpBGKQSDYe
Qw6y/lf8xdL8wS+ZtL1LQdXE1raWtleeqUsF9R2aKJmkpFA9uxqjEclKD4iFzCjhyRyXzH6Hsc/a
mhz6A4aMMw9VkfVMecepG1kDz73sEn5geQ41LyeZNLRAHJZr23ApG3BzUv8Ast8LeBzNeNQ91+Z/
5c2sFrcz+ZtMW1vXCW90LuFoSWExUtKrFEVvqsqhmIUspUHltiqZ6b5m8u6pe3FlpupW17dWgrcx
W8qylPiZCGKEjkrIQy9R36jFUzxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2Ku
xV2KoC88v6Dev6l7ptrdPWvOaCOQ1NN6sp8Mvx6rLAVGUh7iQikP/g/ylv8A7hLDfrS2hH/GuWfn
9R/qk/8ATFaDv8JeXv8Alk/5KSf81Y/nsvf9gWgkY/KLySPNY80/V7gaqgQQsl1PGkfpigoI3QtX
9oOSD4Zm/wAu6nwPAscG/wDCDd+8fdSOEXanpH5R+WNN1PW74M9yuvm/+v280FgKjU5fVuFFzFbR
XhUnYK87ClP5Vpp2SR/9C6eTTLBI2paq3oWMel8TLbEPZh3lnjdvq/Mm5mleWV+XPkfgZF+HFVsv
/OPehLbWwttd1Vr20lW7S5vXguhNdxT3dxDNdAxRvLwk1KaqrInIH4qkVxVE6f8AkPothdapdw+Y
9ckudYurW+vpp5rSd2uNPnFzZuGltXI9CXdV+yRswYUxVJPK/wDzjP5dstI0JNY1C8m1LSnsLuSO
CSE2oubF55isfO3WVoZJ7yV2DnlvsV6YqyvyF+UOjeSdWuL3TL66uLeWKRI4LtllkRpmi9T98ApZ
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ß\18u£\86G\18\17\8b¤\9cÍ\9aBð\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\1dBÁ\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\bWñ\81;´:U\9c\96_\19\1f\91 ILÐ\84éTJ'~Yl,?\ 6¡å5*J\93l\ e\ 6h\12tª\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(À·\15hÓ\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\99ZI\8c\8c,M¬àä¹ÅÉBç£Ì\14\eÐ?¥ª@oût\84õ$©^4õë"\1f Ú\89lR\9e\9bi\12\8e\98p\10\ 6$Â\16[\13jÈ\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}¸\9bM§\9fjL¿Î\80ÅÝãõ\8d\å\99\92óW\15o=/:ÊæÈ(¡ïDÃ\95.Å¥¤\1au\19[\11\1exÔ\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\ eI¥\1e^C< \ f\9c5ÖÖ)\166ÑTó÷\19{\r{ÙðÝá\11«\98ͪ²«ÿ\ 4¼èµ\91\93wéûTÉÂ\92^\88M±1õùAªÙ\ 4Ö4\95ºÅ\18b\8cfï\90Tó¡\aâÌúU]Nìc\0\ 3\8bg°\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?\1cbÞ\94º\ 4epr\14)þ\1f\»añMüQ¿\ 4\96Ø
-®`Õ\8d¬Êdw~è¼SVt`\7f>{¤\878¼sÛá\18&|ó\9e\98h.B¹kµ·BçãÓ=ê*\93·\8aù\8bL¢\ 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 \11Qà\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Ç\19WÒ\7fÔN_\84p?\ f7Wÿß>>?ÿú_\9cü:òJ\ 6ÿ>\ 1ïÛûy\92\86\ 5{\14B÷\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\ 6Fû\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¤\80i©\ e\88¥\92¡\10Yª\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\9egÑ\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\ eqé\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ÍÿĦ\86w¹\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Úóú&\819ú\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\89yè\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\8b9æ\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\8dn»\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\87VÀ\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\9eEä\ 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\8bWÆ\1e¼äÛz£þ6Ûé:¸BHQ,#º\8fÜ«&ü¸p\1d\e^%÷¤\1e³ì0lq\eChOà\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\8bcÁ\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<\ 6UÔ\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«\8af§\96s%\9cÌÖP¹r]ÖRà\14DÕ\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åÆ\97fÝ\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\vkó\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\92rÊ\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\9dA\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£±Vrå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\akï\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\17CÄ\ 5\91<¹ÉÉó[\f\9d\89\8cÂ\9a'¶#«\98\\fÊcÌ,Ú\8b¾AèvI"\93\91\83Q)«¿\9a|:¯lz¶*\ f\91'o
-\ 3¿\8a\107¥\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Ê·\83H¨\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Í\8ba \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Í&\807Ä\1e\867¦¼\e\8b{mlI\8aÍ\1ddî\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\95q©\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¯õ#5g+Q®å`ÌMµ\19\98\ 3Xë\98Q¸\ 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\18T±\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,ÝÍ\89e±\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\rFË\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Å\9dlÖ\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\17ldNéwO\81&E\82\85Ë\8eX\17\83\18»Ý\1eÆ&ÉÛ½ª1ÛØ\9eòS\8còÛ\19üU"~9`¶\13\95iÍ\97nØ\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;?0mJ~\ 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Ä\85Vè\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\11Jí\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\119u"³¨Çüyw\86\97ë^4Q#\9cÐä\aoÒHx\9a\96æd¡1Îcâ¸R0íÊ\¸ ª³g\1e©×d®Zv¶o§Ü&\8a\1a)\91\18K¥\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\0Aý\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\aJÑ\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 ^¯¥\806Þ\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§'ò\91zò\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\12Aù\ 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\ 1bî\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¾Ø£å\9dr¡\84îÂ\9a-ç\ 1%VÆQv\18Ð\86:\a(³F\98Ù\eLË\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\97X\ 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\82RØ\18o¯'8xëfÕ#W\13J§iö\8a\ 6\16\1a®³\9dR¯ó\17\8a\ 6²\86Q´Ó{\1fîsª¢\1d²oÜç\ f\14\rî¢)\9a6+\7f»\8fQÑ\8a\8fÿ³^k\89ëPô x\bZÊE\10(à\8d#â\0\ 5\ 5QÔ\ 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ɼ/£¥ª=\e0Ì\f¶3O\ 33¼\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ä\1aN¥\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\93Læ\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ÆYVÙÐÕ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\11E´\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\fJÕ\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\1clÐ\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\10vÌ\84!\0\b\ 1Ã\8b\97vÕiüÍ{]3\bö¹0\1c-ý0\ 4ßqaH\800¢°a¨\8d/õ\90ªl80Ah¢2<\f\a\ 4\fEö\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¼ú\86F¨\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.¿\9bJë\96Í\93ý-ë\16°Æ7\16^ãsï_é
-@ \96aÂ\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ﺡ*:\8aY¹\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Í\81G½\99V\80±\1e¹»&ühÏ\\8cÀGuß8}\8d\1fEX\92¥\94«É\1eý¡\83\8fnw÷í\1cø(ê\97\8bYõ\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
-\129ø\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¤\10Vki÷ê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ç\8awÏ\ 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\0Wú\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\ 6e¬\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Á\17oã\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\7f1æ\8fÄ]ù¥\84B\1cCVð£n±#\9e\1eJÜ&ò2^û\ 3\13ñ\15Ð\0\1d\97\80ft2\8b¿¤þ\853R\ 2\f\e\94±¬ÀïØÍ \88\1c«n\17mï\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\e9÷\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:\961yóÅ#\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§jtvÇ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¡à¥\ 3uÙ\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Ĭ&¶Ê\98Bþ\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
\17dÂ
\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\8bqû
\ 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ºrNæ¸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\92wô
\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\9deÍ\8fº\99é%\1a^Ïëh¸á{hT\8d|¢qè6\80Æ\17Oìju\15¡WëÜðlµ^\ 4««oeó¸ö-ó\7fy¹\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{\rAí\vBù\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{\9fqø\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\924¾\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ä¯ì\9ec·\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\ eRÉ\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\19TÅ\92R\8bÁEÒ""{\12w´î\92´\9eFý\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\86Kð\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\b2Ê\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\87tÙ\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\ f8Æ\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\93Cï\ 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þ\99Mä\84jãö\1cj¾¾2\15\14\9d§
-\14uVnü\ 3\14ñB&ç´$SA®\0¿(\90ÄM\1cN¡\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\911,ÔrÂ"Ð9c\1aÜ®ùzñ\8bu\8a,äâ\10[7Èê.É\ 1¶n\90\85ê;Äö·È^µ¿ÐÜç#"\12\923\ 6\9aj\91?Ì:w\8cÔË
-Ñ\86SRep\ 4©\99\9aaÚ\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\ 6mü\8b¶q\195 ´ºÀDN\80àFS\18y½\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\930ð\91{M\82\87°e\13þh\12àVÚ± \7f4 à\94vØ\ 4\189ª8\98Ê\80Ç\8c6á\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ñ\rRð\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\1d6á\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\1dI¸\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ÅÁÚ\962Ú\96\94y\bg²\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µò(µ¤Û¯\15BÌ\ 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\1f7ì\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\8bv¾\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[\8co¢\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\92UØ\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\88Vö\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\8fV¸ó4ª\8b\8b\96)b]\rÕ\e\r.¼\1eOÏrmï\ 2÷Ø=exU®ç\91A¹\97wÅ\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+\9a9¹\1aÅÿ\r\1e_Ëý*W+R³Ï¡7*LsÞ\18é\1dx)®ÚõFÿÑi\9a ¾Fq«ì\12\94\r9ñ\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\1cd\7fíU\1c\89ôÀi\12õ\fM</©\12Õ¦\fÚ%ocÔ¥eÙª<\96Ãò¯\17ß]L·\ 6xzÅ)\19\1av¯ÏÀ\14\9d\ 6nvØä \82z1\ 3s×\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\ 3f©\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\8e4¶\9d¾\87Oã\93(\8c\99X5Ý÷\ 4ÝB\86\94Ö\ 5:Ë#\1fJì\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
-îÌóÔ8YÛ\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Ã\94P\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\19Eï\19§©tCQÿÒv1\98îYI/\9d²a4%êÆu9j,\17\8bHá\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\87Iº\14Z5îù«\82\9e_ñ'L\e\18Fo6¦# \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\ 45â\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\98VÊ\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"¡õÂÁ\ 27ï\14m\9f\82þ\8b\84pÝ'\ eË\17qÈùE\10 \83÷ ð4Ö½Rwù\14\84WNC$l8\80>\12tÉ\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/'!\12cÙ\e\9fH\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\9aWã\ 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\9a2Ò\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/ìçÄ\a6º\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/\9bp \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Ø\8doÍ\ 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Â\8byñ\1aÜ\ 5 N\vZX'0?M1´R6D~®\91Pú\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/\fiÒ\ 5\ÉRÄ+\19Òc
-xQ\ fsê\a\7f*\19ÉYJN7\15?\9a4\13"<Ðæ2\93¼\8bÃ\19\93\11ò\8aÌ,\ 2iø\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ù\17K´öªô!©~%çþìQÜS\fò?zç\8f\92\838ð\90X7g_ûPåÝ{³·\89¬ãÃQBÞWÔÃ¥\9fíË\85»rÙ\8a\ 1:\19£\80ÎÛ\8f»Wº6{\9eÄò®à±AòÎà\13ßî§\fE\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\17uÄ\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\16Pâ
-K\ 5\¹\89©BK%\0\8açÂËíªË¬\ 2¿ì®ºÌ*òþ\ eìªË¬Ú¸r\9bv\153\8b:¹\164ê\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¦ß\1aDâ\v\9bÈ\b\8dãë?\1aük¸\19\1c\9eáy*¶@EDZY°\87òL\11\aÍn\14\14W¸\ eßÖU¸F/\ e´ÜLËLùð\98\14\a\Ò)Vߥá@e\96PÃÅ@¨¾¡\89ËÇá\91j\82s\1a\82\86;z\82@Ƨ\19èÚWU¿\ 6H\1aWSdä!Ã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\93b±\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\92A\ 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é\17Q½\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\ 6h¹\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¸\ 5FÞ\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*ú\0hî\92ÊnöH'oÃ;,§2\9b¶Ü!\95i\8cìÝ;,§2½.+©ìhê%³väß\9d+\ 3m¹±ãÝ<³\ 6#oâx7\17 \14½\91Lø%\95Á)\9bÈ\84_R\19¢å\ 62á\97T\ 6=ö]&pð\18ó[¤2¼\8báËvGe\14mù²ÝQ\19E[¾lw®\8c¢-_¶;*£hË\97í\8eÊL®Ü)\95Q4\90\19\1dØ1\95QÞ\ 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¥§\fT¨\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\rYç\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\905¬\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ë@*\1dUÈ\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é·\1fMÖ\ 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\96c÷\17¥$\84è*7lfÔÅóQü¶q\12Ë_çÓ/\89´~¨äıÿܼ¼å\vÝ{©OZ\1fzú\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\89v»\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\85t÷\16\ e\1a)\81\0òÎÍk¤\89\15\97\15Gù\ 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\843Ó\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),ã\12YÂ\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\17Mô\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\ fN»\9dfï\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á\837¤\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Í\81T¼\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ú\92U·\ 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\9ah¢\ 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\115á\18\17\82-/\a\89KAG\0AÈ\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¶æ\84Mâ\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
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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];
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-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}
-}
+++ /dev/null
-\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 an trace as a \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. Given two operations $X$ and $Y$ that are
-both ordering points, the \textit{modification order} edges are as follows:
-
-\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.
+++ /dev/null
-\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.
-
+++ /dev/null
-\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
-
+++ /dev/null
-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*
+++ /dev/null
-\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.
-
-
-
-
+++ /dev/null
-@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},
-}
+++ /dev/null
-%-----------------------------------------------------------------------------
-%
-% Template for sigplanconf LaTeX Class
-%
-% Name: sigplanconf-template.tex
-%
-% Purpose: A template for sigplanconf.cls, which is a LaTeX 2e class
-% file for SIGPLAN conference proceedings.
-%
-% Guide: Refer to "Author's Guide to the ACM SIGPLAN Class,"
-% sigplanconf-guide.pdf
-%
-% Author: Paul C. Anagnostopoulos
-% Windfall Software
-% 978 371-2316
-% paul@windfall.com
-%
-% Created: 15 February 2005
-%
-%-----------------------------------------------------------------------------
-
-
-\documentclass[nocopyrightspace]{sig-alternate}
-
-% The following \documentclass options may be useful:
-%
-% 10pt To set in 10-point type instead of 9-point.
-% 11pt To set in 11-point type instead of 9-point.
-% authoryear To obtain author/year citation style instead of numeric.
-\usepackage{times}
-\usepackage[scaled]{helvet} % see www.ctan.org/get/macros/latex/required/psnfss/psnfss2e.pdf
-\usepackage{url} % format URLs
-\usepackage{listings} % format code
-\usepackage{enumitem} % adjust spacing in enums
-\sloppy
-\usepackage[colorlinks=true,allcolors=blue,breaklinks,draft]{hyperref}
-\newcommand{\doi}[1]{doi:~\href{http://dx.doi.org/#1}{\Hurl{#1}}} % print a hyperlinked DOI
-
-\usepackage{rotating}
-\usepackage{algorithm}% http://ctan.org/pkg/algorithms
-\usepackage{algpseudocode}% http://ctan.org/pkg/algorithmicx
-%\usepackage{syntax}
-%\usepackage{times}
-
-\usepackage{amsmath}
-\usepackage{graphicx}
-\usepackage{xspace}
-\usepackage{amssymb}
-
-\usepackage{listings}
-\usepackage{color}
-\usepackage{textcomp}
-\definecolor{listinggray}{gray}{0.9}
-\definecolor{lbcolor}{rgb}{0.9,0.9,0.9}
-\lstset{
- % backgroundcolor=\color{lbcolor},
- % rulecolor=,
- % aboveskip={1.5\baselineskip},
- % extendedchars=true,
- tabsize=3,
- language=C++,
- basicstyle=\ttfamily\scriptsize,
- upquote=true,
- columns=fixed,
- showstringspaces=false,
- breaklines=true,
- prebreak = \raisebox{0ex}[0ex][0ex]{\ensuremath{\hookleftarrow}},
- % frame=single,
- showtabs=false,
- showspaces=false,
- showstringspaces=false,
- identifierstyle=\ttfamily,
- keywordstyle=\color[rgb]{0,0,1},
- commentstyle=\color[rgb]{0.133,0.545,0.133},
- stringstyle=\color[rgb]{0.627,0.126,0.941},
- numbers=left,
- numberstyle=\tiny,
- numbersep=8pt,
- escapeinside={/*@}{@*/}
-}
-
-\usepackage{algpseudocode}
-
-%% Not used yet
-% \usepackage{times}
-% \usepackage{latexsym}
-% \usepackage{amsfonts}
-% \usepackage{amsthm}
-% \usepackage{txfonts}
-% \usepackage{url}
-% \usepackage{subfigure}
-
-% \usepackage{bbm}
-% \usepackage{stfloats}
-
-\newcommand{\squishlist}{
- \begin{list}{$\bullet$}
- {
- \setlength{\itemsep}{1pt}
- \setlength{\parsep}{1pt}
- \setlength{\topsep}{1pt}
- \setlength{\partopsep}{1pt}
- \setlength{\leftmargin}{1em}
- \setlength{\labelwidth}{0.5em}
- \setlength{\labelsep}{0.5em}
- }
-}
-
-\newcommand{\squishend}{
- \end{list}
-}
-
-\newcommand{\squishcount}{
-% \begin{enumerate}
-%}
- \begin{list}{\bf \arabic{enumi}.}
- { \usecounter{enumi}
- \setlength{\itemsep}{1pt} \setlength{\parsep}{0pt}
- \setlength{\topsep}{0pt} \setlength{\partopsep}{0pt}
- \setlength{\leftmargin}{1em} \setlength{\labelwidth}{0.5em}
- \setlength{\labelsep}{0.5em} } }
-
-\newcommand{\countend}{
-% \end{enumerate}
-%}
-\end{list}}
-
-
-\newcommand{\code}[1]{\text{\tt #1}}
-\newcommand{\mypara}[1]{\noindent {#1}}
-\newcommand{\etal}{\textit{et al}.\xspace}
-\newcommand{\cdschecker}[0]{\textsc{CDSChecker}\xspace}
-\newcommand{\TOOL}[0]{\textsc{CDSSpec}\xspace}
-
-\newcommand{\TODO}[0]{\textbf{TODO}\xspace}
-\newcommand{\todo}[1]{{\bf [[#1]]}}
-%\newcommand{\todo}[1]{}
-\newcommand{\comment}[1]{}
-\newcommand{\tuple}[1]{\ensuremath \langle #1 \rangle}
-\newcommand{\rf}{\reltext{rf}}
-\newcommand{\relation}[1]{\xrightarrow{\textit{#1}}}
-\newcommand{\reltext}[1]{\textit{#1}}
-
-%\newcommand{\mysection}[1]{\vspace{-.15cm}\section{#1}\vspace{-.15cm}}
-\newcommand{\mysection}[1]{\section{#1}}
-%\newcommand{\mysubsection}[1]{\vspace{-.15cm}\subsection{#1}\vspace{-.1cm}}
-\newcommand{\mysubsection}[1]{\subsection{#1}}
-%\newcommand{\mysubsubsection}[1]{\vspace{-.15cm}\subsubsection{#1}\vspace{-.1cm}}
-\newcommand{\mysubsubsection}[1]{\subsubsection{#1}}
-\begin{document}
-
-
-\sloppy
-
-\title{CDSSpec: Testing Concurrent Data Structures Under the C/C++11 Memory Model}
-
-\author{Peizhao Ou and Brian Demsky}
-
-
-
-\maketitle
-
-\begin{abstract}
-\input{abstract}
-\end{abstract}
-
-\input{introduction}
-%\input{memorymodel}
-%\input{example}
-\input{formalization}
-%\input{specification}
-%\input{implementation}
-%\input{evaluation}
-%\input{related}
-%\input{conclusion}
-
-
-% We recommend abbrvnat bibliography style.
-\bibliographystyle{abbrv}
-\bibliography{confstrs-long,paper}
-
-\end{document}
+++ /dev/null
-\mysection{\label{sec:related}Related Work}
-
-% Related work should be related to bug finding on concurrent data structures:
-% 1. Specification:
-% CONCURRIT: A Domain Specific Language for Reproducing Concurrency Bugs (DSL
-% for reproducing bugs, allowing specifying a set of thread schedules to explore
-% in order to exhibit the bug) (PLDI'13)
-
-% <NDSeq: Runtime Checking for Nondeterministic Sequential Specifications of
-% Parallel Correctness> (specify the correctness of concurrent programs using
-% nondeterministic sequential specifications, which allows the functional
-% correctness to be understood and verified on a sequential version of the
-% program) (PLDI'11)
-
-% <NDetermin: Inferring Nondeterministic Sequential Specifications for
-% Parallelism Correctness> (this is the extended work of NDSeq, which is
-% inferring the specification) (ppopp'12)
-
-% <VYRD: VerifYing Concurrent Programs by Runtime Refinement-Violation
-% Detection> (specification, not exhaustive approach, dynamic checking)
-% (PLDI'05)
-
-
-% 2. Linearizability:
-% <Verifying Commit-Atomicity using Model-Checking> (a more complete technique
-% for verifying atomicity using SPIN model checker)(SPIN Workshop'04)
-
-% <The existence of Refinement mapping> (theoretical paper about proving a lower
-% level spscification correctly implements a higher level one) (Theoretical
-% Computer Science'91)
-
-% <Comparison Under Abstraction for Verifying Linearizability> (static analysis
-% for verifying linearizability of concurrent unbounded linked data
-% structures) (CAV'07)
-
-% <Formal Verification of a Lazy Concurrent List-Based Set Algorithm> (a formal
-% verification of LazyList, concurrent list-based set algorithm, shows it's
-% linearizable) (CAV'06)
-
-% <Line-Up: A Complete and Automatic Linearizability Checker> (no specification,
-% run a sequential version in parallel and checks if the concurrent execution
-% violates linearizability, rely on CHESS, which assumes SC) (PLDI'10)
-
-% <Thread Quantification for Concurrent Shape Analysis> (using abstract
-% interpretation, shape analysis for concurrent data structures, can prove
-% linearizability in a limited way) (CAV'08)
-
-% <Experience with Model Checking Linearizability> (SC-based checking
-% linearizability) (SPIN Workshop'09)
-
-% <Shape-Value Abstraction for Verifying Linearizability> (heap-allocated data
-% structures, shape analysis, assuming SC) (VMCAI'09)
-
-% 3. General concurrency testing
-% <GAMBIT: Effective Unit Testing for Concurrency Libraries> (a prioritized
-% search technique that combines the speed benefit of heuristic-guided fuzzing
-% with the soundness, progress, and reproducibility of stateless model checking)
-% (ppopp'10)
-
-% <Testing and Verifying Concurrent Objects> (one of the early paper) (Journal of Parallel and
-% Distributed Computing)
-
-% 4. For relaxed M.M.
-% <CheckFence: Checking Consistency of Concurrent Data Types on Relaxed Memory
-% Models> () (PLDI'07) (TODO: Should read this in more detail)
-
-% <Testing Concurrent Programs on Relaxed Memory Models> (a tool that test
-% concurrent programs under relaxed M.M., but no specification, and not
-% an exhaustive approach) (issta'11)
-
-Researchers have proposed and designed specifications and approaches
-to find bugs in concurrent data structures based on linearization.
-Early work by Wing and
-Gong~\cite{test-verify-concurrent-objects} proposed using
-linearizability to test and verify concurrent objects.
-Line-up~\cite{lineup} builds on the Chess~\cite{chess} model checker
-to automatically check deterministic linearizability. It
-automatically generates the sequential specification by systematically
-enumerating all sequential behaviors.
-Paraglider~\cite{VechevMCLinear} supports checking with and without
-linearization points based on SPIN~\cite{spinmodel}. All of these
-approaches assume that there exist a sequential history that is consistent with program order. Furthermore, they also assume
-the SC memory model and a trace that provides an
-ordering for method invocation and response events. Our work extends the notion of equivalence to sequential executions to the relaxed memory models used
-by real systems.
-
-Amit \etal~\cite{abstraction-linearizability} present a static
-analysis based on TVLA for verifying linearizability of concurrent
-linked data structures. Valeiadis~\cite{shape-value-abstraction}
-demonstrates a shape-value abstraction which can automatically prove
-linearizability. Thread quantification can also verify
-data structure linearizability~\cite{thread-quantification}.
-Colvin \etal formally verified a list-based set~\cite{formal-verification-set}. While these approaches
-provide stronger guarantees than \TOOL, they were typically used to
-check simpler data structures and require experts to use.
-Moreover, they target the SC memory model.
-
-Researchers have proposed specification languages for concurrent
-data structures. Refinement mapping~\cite{refinement-mapping}
-provides the theoretical basis for designing and using specifications.
-Commit atomicity~\cite{spin-commit-atomicity} can verify atomicity
-properties. Concurrit~\cite{concurrit} is a domain-specific language
-that allows programmers to write scripts to specify thread schedules
-to reproduce bugs, and is useful when programmers already have some
-knowledge about a bug. NDetermin~\cite{ndetermin} infers
-nondeterministic sequential specifications to model the behaviors of
-parallel code.
-
-VYRD~\cite{vyrd} is conceptually similar to \TOOL --- developers
-specify commit points for concurrent code. The parallel code is then
-executed and the commit points are used to identify a sequential
-execution that should have the same behaviors. VYRD was designed for
-the SC memory model --- it
-is unable to construct a sequential refinement for a relaxed memory
-model or check synchronization properties.
-
-{\sc Gambit}~\cite{gambit} uses a prioritized search technique that
-combines stateless model checking and heuristic-guided fuzzing to unit
-test code under the SC memory model. {\sc Relaxed}~\cite{memtest}
-explores SC executions to identify executions with races and then
-re-executes the program under the PSO or TSO memory model to test
-whether the relaxations expose bugs. CheckFence~\cite{checkfence} is
-a tool for verifying data structures against relaxed memory models and
-takes a SAT-based approach instead of the stateless model checking
-approach used by \cdschecker.
-
-Researchers have developed verification techniques for code that
-admits only SC executions under the TSO and PSO memory
-models~\cite{koushiksc,burckhardtverif}. The basic idea is to develop
-an execution monitor that can detect whether non-SC executions exist
-by examining only SC executions.
-
-
+++ /dev/null
-% SIG-ALTERNATE.CLS - VERSION 2.5\r
-% "COMPATIBLE" WITH THE "ACM_PROC_ARTICLE-SP.CLS" V3.2SP\r
-% Gerald Murray - May 23rd 2012\r
-%\r
-% ---- Start of 'updates' ----\r
-% Changed $10 fee to $15 -- May 2012 -- Gerry\r
-% Changed $5 fee to $10 -- April 2009 -- Gerry\r
-% April 22nd. 2009 - Fixed 'Natbib' incompatibility problem - Gerry\r
-% April 22nd. 2009 - Fixed 'Babel' incompatibility problem - Gerry\r
-% April 22nd. 2009 - Inserted various bug-fixes and improvements - Gerry\r
-%\r
-% To produce Type 1 fonts in the document plus allow for 'normal LaTeX accenting' in the critical areas;\r
-% title, author block, section-heads, confname, etc. etc. \r
-% i.e. the whole purpose of this version update is to NOT resort to 'inelegant accent patches'.\r
-% After much research, three extra .sty packages were added to the the tail (ae, aecompl, aeguill) to solve,\r
-% in particular, the accenting problem(s). We _could_ ask authors (via instructions/sample file) to 'include' these in\r
-% the source .tex file - in the preamble - but if everything is already provided ('behind the scenes' - embedded IN the .cls)\r
-% then this is less work for authors and also makes everything appear 'vanilla'.\r
-% NOTE: all 'patchwork accenting" has been commented out (here) and is no longer 'used' in the sample .tex file (either).\r
-% Gerry June 2007\r
-%\r
-% Patch for accenting in conference name/location. Gerry May 3rd. 2007\r
-% Rule widths changed to .5, author count (>6) fixed, roll-back for Type 3 problem. Gerry March 20th. 2007\r
-% Changes made to 'modernize' the fontnames but esp. for MikTeX users V2.4/2.5 - Nov. 30th. 2006\r
-% Updated the \email definition to allow for its use inside of 'shared affiliations' - Nov. 30th. 2006\r
-% Fixed the 'section number depth value' - Nov. 30th. 2006\r
-%\r
-% Footnotes inside table cells using \minipage (Oct. 2002)\r
-% Georgia fixed bug in sub-sub-section numbering in paragraphs (July 29th. 2002)\r
-% JS/GM fix to vertical spacing before Proofs (July 30th. 2002)\r
-%\r
-% Made the Permission Statement / Conference Info / Copyright Info\r
-% 'user definable' in the source .tex file OR automatic if\r
-% not specified.\r
-%\r
-% Allowance made to switch default fonts between those systems using\r
-% normal/modern font names and those using 'Type 1' or 'Truetype' fonts.\r
-% See LINE NUMBER 255 for details.\r
-% Also provided for enumerated/annotated Corollaries 'surrounded' by\r
-% enumerated Theorems (line 848).\r
-% Gerry November 11th. 1999\r
-%\r
-% ---- End of 'updates' ----\r
-%\r
-\def\fileversion{v2.5} % for ACM's tracking purposes\r
-\def\filedate{May 23, 2012} % Gerry Murray's tracking data\r
-\def\docdate {Wednesday 23rd. May 2012} % Gerry Murray (with deltas to doc}\r
-\usepackage{epsfig}\r
-\usepackage{amssymb}\r
-\usepackage{amsmath}\r
-\usepackage{amsfonts}\r
-% Need this for accents in Arial/Helvetica\r
-%\usepackage[T1]{fontenc} % Gerry March 12, 2007 - causes Type 3 problems (body text)\r
-%\usepackage{textcomp}\r
-%\r
-% SIG-ALTERNATE DOCUMENT STYLE\r
-% G.K.M. Tobin August-October 1999\r
-% adapted from ARTICLE document style by Ken Traub, Olin Shivers\r
-% also using elements of esub2acm.cls\r
-% HEAVILY MODIFIED, SUBSEQUENTLY, BY GERRY MURRAY 2000\r
-% ARTICLE DOCUMENT STYLE -- Released 16 March 1988\r
-% for LaTeX version 2.09\r
-% Copyright (C) 1988 by Leslie Lamport\r
-%\r
-%\r
-%%% sig-alternate.cls is an 'ALTERNATE' document style for producing\r
-%%% two-column camera-ready pages for ACM conferences.\r
-%%% THIS FILE DOES NOT STRICTLY ADHERE TO THE SIGS (BOARD-ENDORSED)\r
-%%% PROCEEDINGS STYLE. It has been designed to produce a 'tighter'\r
-%%% paper in response to concerns over page budgets.\r
-%%% The main features of this style are:\r
-%%%\r
-%%% 1) Two columns.\r
-%%% 2) Side and top margins of 4.5pc, bottom margin of 6pc, column gutter of\r
-%%% 2pc, hence columns are 20pc wide and 55.5pc tall. (6pc =3D 1in, approx)\r
-%%% 3) First page has title information, and an extra 6pc of space at the\r
-%%% bottom of the first column for the ACM copyright notice.\r
-%%% 4) Text is 9pt on 10pt baselines; titles (except main) are 9pt bold.\r
-%%%\r
-%%%\r
-%%% There are a few restrictions you must observe:\r
-%%%\r
-%%% 1) You cannot change the font size; ACM wants you to use 9pt.\r
-%%% 3) You must start your paper with the \maketitle command. Prior to the\r
-%%% \maketitle you must have \title and \author commands. If you have a\r
-%%% \date command it will be ignored; no date appears on the paper, since\r
-%%% the proceedings will have a date on the front cover.\r
-%%% 4) Marginal paragraphs, tables of contents, lists of figures and tables,\r
-%%% and page headings are all forbidden.\r
-%%% 5) The `figure' environment will produce a figure one column wide; if you\r
-%%% want one that is two columns wide, use `figure*'.\r
-%%%\r
-%\r
-%%% Copyright Space:\r
-%%% This style automatically reserves 1" blank space at the bottom of page 1/\r
-%%% column 1. This space can optionally be filled with some text using the\r
-%%% \toappear{...} command. If used, this command must be BEFORE the \maketitle\r
-%%% command. If this command is defined AND [preprint] is on, then the\r
-%%% space is filled with the {...} text (at the bottom); otherwise, it is\r
-%%% blank. If you use \toappearbox{...} instead of \toappear{...} then a\r
-%%% box will be drawn around the text (if [preprint] is on).\r
-%%%\r
-%%% A typical usage looks like this:\r
-%%% \toappear{To appear in the Ninth AES Conference on Medievil Lithuanian\r
-%%% Embalming Technique, June 1991, Alfaretta, Georgia.}\r
-%%% This will be included in the preprint, and left out of the conference\r
-%%% version.\r
-%%%\r
-%%% WARNING:\r
-%%% Some dvi-ps converters heuristically allow chars to drift from their\r
-%%% true positions a few pixels. This may be noticeable with the 9pt sans-serif\r
-%%% bold font used for section headers.\r
-%%% You may turn this hackery off via the -e option:\r
-%%% dvips -e 0 foo.dvi >foo.ps\r
-%%%\r
-\typeout{Document Class 'sig-alternate' <23rd. May '12>. Modified by G.K.M. Tobin/Gerry Murray}\r
-\typeout{Based in part upon document Style `acmconf' <22 May 89>. Hacked 4/91 by}\r
-\typeout{shivers@cs.cmu.edu, 4/93 by theobald@cs.mcgill.ca}\r
-\typeout{Excerpts were taken from (Journal Style) 'esub2acm.cls'.}\r
-\typeout{****** Bugs/comments/suggestions/technicalities to Gerry Murray -- murray@hq.acm.org ******}\r
-\typeout{Questions on the style, SIGS policies, etc. to Adrienne Griscti griscti@acm.org}\r
-\oddsidemargin 4.5pc\r
-\evensidemargin 4.5pc\r
-\advance\oddsidemargin by -1in % Correct for LaTeX gratuitousness\r
-\advance\evensidemargin by -1in % Correct for LaTeX gratuitousness\r
-\marginparwidth 0pt % Margin pars are not allowed.\r
-\marginparsep 11pt % Horizontal space between outer margin and\r
- % marginal note\r
-\r
- % Top of page:\r
-\topmargin 4.5pc % Nominal distance from top of page to top of\r
- % box containing running head.\r
-\advance\topmargin by -1in % Correct for LaTeX gratuitousness\r
-\headheight 0pt % Height of box containing running head.\r
-\headsep 0pt % Space between running head and text.\r
- % Bottom of page:\r
-\footskip 30pt % Distance from baseline of box containing foot\r
- % to baseline of last line of text.\r
-\@ifundefined{footheight}{\newdimen\footheight}{}% this is for LaTeX2e\r
-\footheight 12pt % Height of box containing running foot.\r
-\r
-%% Must redefine the top margin so there's room for headers and\r
-%% page numbers if you are using the preprint option. Footers\r
-%% are OK as is. Olin.\r
-\advance\topmargin by -37pt % Leave 37pt above text for headers\r
-\headheight 12pt % Height of box containing running head.\r
-\headsep 25pt % Space between running head and text.\r
-\r
-\textheight 666pt % 9 1/4 column height\r
-\textwidth 42pc % Width of text line.\r
- % For two-column mode:\r
-\columnsep 2pc % Space between columns\r
-\columnseprule 0pt % Width of rule between columns.\r
-\hfuzz 1pt % Allow some variation in column width, otherwise it's\r
- % too hard to typeset in narrow columns.\r
-\r
-\footnotesep 5.6pt % Height of strut placed at the beginning of every\r
- % footnote =3D height of normal \footnotesize strut,\r
- % so no extra space between footnotes.\r
-\r
-\skip\footins 8.1pt plus 4pt minus 2pt % Space between last line of text and\r
- % top of first footnote.\r
-\floatsep 11pt plus 2pt minus 2pt % Space between adjacent floats moved\r
- % to top or bottom of text page.\r
-\textfloatsep 18pt plus 2pt minus 4pt % Space between main text and floats\r
- % at top or bottom of page.\r
-\intextsep 11pt plus 2pt minus 2pt % Space between in-text figures and\r
- % text.\r
-\@ifundefined{@maxsep}{\newdimen\@maxsep}{}% this is for LaTeX2e\r
-\@maxsep 18pt % The maximum of \floatsep,\r
- % \textfloatsep and \intextsep (minus\r
- % the stretch and shrink).\r
-\dblfloatsep 11pt plus 2pt minus 2pt % Same as \floatsep for double-column\r
- % figures in two-column mode.\r
-\dbltextfloatsep 18pt plus 2pt minus 4pt% \textfloatsep for double-column\r
- % floats.\r
-\@ifundefined{@dblmaxsep}{\newdimen\@dblmaxsep}{}% this is for LaTeX2e\r
-\@dblmaxsep 18pt % The maximum of \dblfloatsep and\r
- % \dbltexfloatsep.\r
-\@fptop 0pt plus 1fil % Stretch at top of float page/column. (Must be\r
- % 0pt plus ...)\r
-\@fpsep 8pt plus 2fil % Space between floats on float page/column.\r
-\@fpbot 0pt plus 1fil % Stretch at bottom of float page/column. (Must be\r
- % 0pt plus ... )\r
-\@dblfptop 0pt plus 1fil % Stretch at top of float page. (Must be 0pt plus ...)\r
-\@dblfpsep 8pt plus 2fil % Space between floats on float page.\r
-\@dblfpbot 0pt plus 1fil % Stretch at bottom of float page. (Must be\r
- % 0pt plus ... )\r
-\marginparpush 5pt % Minimum vertical separation between two marginal\r
- % notes.\r
-\r
-\parskip 0pt plus 1pt % Extra vertical space between paragraphs.\r
-\parindent 9pt % GM July 2000 / was 0pt - width of paragraph indentation.\r
-\partopsep 2pt plus 1pt minus 1pt% Extra vertical space, in addition to\r
- % \parskip and \topsep, added when user\r
- % leaves blank line before environment.\r
-\r
-\@lowpenalty 51 % Produced by \nopagebreak[1] or \nolinebreak[1]\r
-\@medpenalty 151 % Produced by \nopagebreak[2] or \nolinebreak[2]\r
-\@highpenalty 301 % Produced by \nopagebreak[3] or \nolinebreak[3]\r
-\r
-\@beginparpenalty -\@lowpenalty % Before a list or paragraph environment.\r
-\@endparpenalty -\@lowpenalty % After a list or paragraph environment.\r
-\@itempenalty -\@lowpenalty % Between list items.\r
-\r
-%\@namedef{ds@10pt}{\@latexerr{The `10pt' option is not allowed in the `acmconf'\r
-\@namedef{ds@10pt}{\ClassError{The `10pt' option is not allowed in the `acmconf' % January 2008\r
- document style.}\@eha}\r
-%\@namedef{ds@11pt}{\@latexerr{The `11pt' option is not allowed in the `acmconf'\r
-\@namedef{ds@11pt}{\ClassError{The `11pt' option is not allowed in the `acmconf' % January 2008\r
- document style.}\@eha}\r
-%\@namedef{ds@12pt}{\@latexerr{The `12pt' option is not allowed in the `acmconf'\r
-\@namedef{ds@12pt}{\ClassError{The `12pt' option is not allowed in the `acmconf' % January 2008\r
- document style.}\@eha}\r
-\r
-\@options\r
-\r
-\lineskip 2pt % \lineskip is 1pt for all font sizes.\r
-\normallineskip 2pt\r
-\def\baselinestretch{1}\r
-\r
-\abovedisplayskip 9pt plus2pt minus4.5pt%\r
-\belowdisplayskip \abovedisplayskip\r
-\abovedisplayshortskip \z@ plus3pt%\r
-\belowdisplayshortskip 5.4pt plus3pt minus3pt%\r
-\let\@listi\@listI % Setting of \@listi added 9 Jun 87\r
-\r
-\def\small{\@setsize\small{9pt}\viiipt\@viiipt\r
-\abovedisplayskip 7.6pt plus 3pt minus 4pt%\r
-\belowdisplayskip \abovedisplayskip\r
-\abovedisplayshortskip \z@ plus2pt%\r
-\belowdisplayshortskip 3.6pt plus2pt minus 2pt\r
-\def\@listi{\leftmargin\leftmargini %% Added 22 Dec 87\r
-\topsep 4pt plus 2pt minus 2pt\parsep 2pt plus 1pt minus 1pt\r
-\itemsep \parsep}}\r
-\r
-\def\footnotesize{\@setsize\footnotesize{9pt}\ixpt\@ixpt\r
-\abovedisplayskip 6.4pt plus 2pt minus 4pt%\r
-\belowdisplayskip \abovedisplayskip\r
-\abovedisplayshortskip \z@ plus 1pt%\r
-\belowdisplayshortskip 2.7pt plus 1pt minus 2pt\r
-\def\@listi{\leftmargin\leftmargini %% Added 22 Dec 87\r
-\topsep 3pt plus 1pt minus 1pt\parsep 2pt plus 1pt minus 1pt\r
-\itemsep \parsep}}\r
-\r
-\newcount\aucount\r
-\newcount\originalaucount\r
-\newdimen\auwidth\r
-\auwidth=\textwidth\r
-\newdimen\auskip\r
-\newcount\auskipcount\r
-\newdimen\auskip\r
-\global\auskip=1pc\r
-\newdimen\allauboxes\r
-\allauboxes=\auwidth\r
-\newtoks\addauthors\r
-\newcount\addauflag\r
-\global\addauflag=0 %Haven't shown additional authors yet\r
-\r
-\newtoks\subtitletext\r
-\gdef\subtitle#1{\subtitletext={#1}}\r
-\r
-\gdef\additionalauthors#1{\addauthors={#1}}\r
-\r
-\gdef\numberofauthors#1{\global\aucount=#1\r
-\ifnum\aucount>3\global\originalaucount=\aucount \global\aucount=3\fi %g} % 3 OK - Gerry March 2007\r
-\global\auskipcount=\aucount\global\advance\auskipcount by 1\r
-\global\multiply\auskipcount by 2\r
-\global\multiply\auskip by \auskipcount\r
-\global\advance\auwidth by -\auskip\r
-\global\divide\auwidth by \aucount}\r
-\r
-% \and was modified to count the number of authors. GKMT 12 Aug 1999\r
-\def\alignauthor{% % \begin{tabular}\r
-\end{tabular}%\r
- \begin{tabular}[t]{p{\auwidth}}\centering}%\r
-\r
-% *** NOTE *** NOTE *** NOTE *** NOTE ***\r
-% If you have 'font problems' then you may need\r
-% to change these, e.g. 'arialb' instead of "arialbd".\r
-% Gerry Murray 11/11/1999\r
-% *** OR ** comment out block A and activate block B or vice versa.\r
-% **********************************************\r
-%\r
-% -- Start of block A -- (Type 1 or Truetype fonts)\r
-%\newfont{\secfnt}{timesbd at 12pt} % was timenrb originally - now is timesbd\r
-%\newfont{\secit}{timesbi at 12pt} %13 Jan 00 gkmt\r
-%\newfont{\subsecfnt}{timesi at 11pt} % was timenrri originally - now is timesi\r
-%\newfont{\subsecit}{timesbi at 11pt} % 13 Jan 00 gkmt -- was times changed to timesbi gm 2/4/2000\r
-% % because "normal" is italic, "italic" is Roman\r
-%\newfont{\ttlfnt}{arialbd at 18pt} % was arialb originally - now is arialbd\r
-%\newfont{\ttlit}{arialbi at 18pt} % 13 Jan 00 gkmt\r
-%\newfont{\subttlfnt}{arial at 14pt} % was arialr originally - now is arial\r
-%\newfont{\subttlit}{ariali at 14pt} % 13 Jan 00 gkmt\r
-%\newfont{\subttlbf}{arialbd at 14pt} % 13 Jan 00 gkmt\r
-%\newfont{\aufnt}{arial at 12pt} % was arialr originally - now is arial\r
-%\newfont{\auit}{ariali at 12pt} % 13 Jan 00 gkmt\r
-%\newfont{\affaddr}{arial at 10pt} % was arialr originally - now is arial\r
-%\newfont{\affaddrit}{ariali at 10pt} %13 Jan 00 gkmt\r
-%\newfont{\eaddfnt}{arial at 12pt} % was arialr originally - now is arial\r
-%\newfont{\ixpt}{times at 9pt} % was timenrr originally - now is times\r
-%\newfont{\confname}{timesi at 8pt} % was timenrri - now is timesi\r
-%\newfont{\crnotice}{times at 8pt} % was timenrr originally - now is times\r
-%\newfont{\ninept}{times at 9pt} % was timenrr originally - now is times\r
-\r
-% *********************************************\r
-% -- End of block A --\r
-%\r
-%\r
-% -- Start of block B -- UPDATED FONT NAMES\r
-% *********************************************\r
-% Gerry Murray 11/30/2006\r
-% *********************************************\r
-\newfont{\secfnt}{ptmb8t at 12pt}\r
-\newfont{\secit}{ptmbi8t at 12pt} %13 Jan 00 gkmt\r
-\newfont{\subsecfnt}{ptmri8t at 11pt}\r
-\newfont{\subsecit}{ptmbi8t at 11pt} % \r
-\newfont{\ttlfnt}{phvb8t at 18pt}\r
-\newfont{\ttlit}{phvbo8t at 18pt} % GM 2/4/2000\r
-\newfont{\subttlfnt}{phvr8t at 14pt}\r
-\newfont{\subttlit}{phvro8t at 14pt} % GM 2/4/2000\r
-\newfont{\subttlbf}{phvb8t at 14pt} % 13 Jan 00 gkmt\r
-\newfont{\aufnt}{phvr8t at 12pt}\r
-\newfont{\auit}{phvro8t at 12pt} % GM 2/4/2000\r
-\newfont{\affaddr}{phvr8t at 10pt}\r
-\newfont{\affaddrit}{phvro8t at 10pt} % GM 2/4/2000\r
-\newfont{\eaddfnt}{phvr8t at 12pt}\r
-\newfont{\ixpt}{ptmr8t at 9pt}\r
-\newfont{\confname}{ptmri8t at 8pt}\r
-\newfont{\crnotice}{ptmr8t at 8pt}\r
-\newfont{\ninept}{ptmr8t at 9pt}\r
-% +++++++++++++++++++++++++++++++++++++++++++++\r
-% -- End of block B --\r
-\r
-%\def\email#1{{{\eaddfnt{\vskip 4pt#1}}}}\r
-% If we have an email, inside a "shared affiliation" then we need the following instead\r
-\def\email#1{{{\eaddfnt{\par #1}}}} % revised - GM - 11/30/2006\r
-\r
-\def\addauthorsection{\ifnum\originalaucount>6 % was 3 - Gerry March 2007\r
- \section{Additional Authors}\the\addauthors\r
- \fi}\r
-\r
-\newcount\savesection\r
-\newcount\sectioncntr\r
-\global\sectioncntr=1\r
-\r
-\setcounter{secnumdepth}{3}\r
-\r
-\def\appendix{\par\r
-\section*{APPENDIX}\r
-\setcounter{section}{0}\r
- \setcounter{subsection}{0}\r
- \def\thesection{\Alph{section}} }\r
-\r
-\leftmargini 22.5pt\r
-\leftmarginii 19.8pt % > \labelsep + width of '(m)'\r
-\leftmarginiii 16.8pt % > \labelsep + width of 'vii.'\r
-\leftmarginiv 15.3pt % > \labelsep + width of 'M.'\r
-\leftmarginv 9pt\r
-\leftmarginvi 9pt\r
-\r
-\leftmargin\leftmargini\r
-\labelsep 4.5pt\r
-\labelwidth\leftmargini\advance\labelwidth-\labelsep\r
-\r
-\def\@listI{\leftmargin\leftmargini \parsep 3.6pt plus 2pt minus 1pt%\r
-\topsep 7.2pt plus 2pt minus 4pt%\r
-\itemsep 3.6pt plus 2pt minus 1pt}\r
-\r
-\let\@listi\@listI\r
-\@listi\r
-\r
-\def\@listii{\leftmargin\leftmarginii\r
- \labelwidth\leftmarginii\advance\labelwidth-\labelsep\r
- \topsep 3.6pt plus 2pt minus 1pt\r
- \parsep 1.8pt plus 0.9pt minus 0.9pt\r
- \itemsep \parsep}\r
-\r
-\def\@listiii{\leftmargin\leftmarginiii\r
- \labelwidth\leftmarginiii\advance\labelwidth-\labelsep\r
- \topsep 1.8pt plus 0.9pt minus 0.9pt\r
- \parsep \z@ \partopsep 1pt plus 0pt minus 1pt\r
- \itemsep \topsep}\r
-\r
-\def\@listiv{\leftmargin\leftmarginiv\r
- \labelwidth\leftmarginiv\advance\labelwidth-\labelsep}\r
-\r
-\def\@listv{\leftmargin\leftmarginv\r
- \labelwidth\leftmarginv\advance\labelwidth-\labelsep}\r
-\r
-\def\@listvi{\leftmargin\leftmarginvi\r
- \labelwidth\leftmarginvi\advance\labelwidth-\labelsep}\r
-\r
-\def\labelenumi{\theenumi.}\r
-\def\theenumi{\arabic{enumi}}\r
-\r
-\def\labelenumii{(\theenumii)}\r
-\def\theenumii{\alph{enumii}}\r
-\def\p@enumii{\theenumi}\r
-\r
-\def\labelenumiii{\theenumiii.}\r
-\def\theenumiii{\roman{enumiii}}\r
-\def\p@enumiii{\theenumi(\theenumii)}\r
-\r
-\def\labelenumiv{\theenumiv.}\r
-\def\theenumiv{\Alph{enumiv}}\r
-\def\p@enumiv{\p@enumiii\theenumiii}\r
-\r
-\def\labelitemi{$\bullet$}\r
-\def\labelitemii{\bf --}\r
-\def\labelitemiii{$\ast$}\r
-\def\labelitemiv{$\cdot$}\r
-\r
-\def\verse{\let\\=\@centercr\r
- \list{}{\itemsep\z@ \itemindent -1.5em\listparindent \itemindent\r
- \rightmargin\leftmargin\advance\leftmargin 1.5em}\item[]}\r
-\let\endverse\endlist\r
-\r
-\def\quotation{\list{}{\listparindent 1.5em\r
- \itemindent\listparindent\r
- \rightmargin\leftmargin \parsep 0pt plus 1pt}\item[]}\r
-\let\endquotation=\endlist\r
-\r
-\def\quote{\list{}{\rightmargin\leftmargin}\item[]}\r
-\let\endquote=\endlist\r
-\r
-\def\descriptionlabel#1{\hspace\labelsep \bf #1}\r
-\def\description{\list{}{\labelwidth\z@ \itemindent-\leftmargin\r
- \let\makelabel\descriptionlabel}}\r
-\r
-\let\enddescription\endlist\r
-\r
-\def\theequation{\arabic{equation}}\r
-\r
-\arraycolsep 4.5pt % Half the space between columns in an array environment.\r
-\tabcolsep 5.4pt % Half the space between columns in a tabular environment.\r
-\arrayrulewidth .5pt % Width of rules in array and tabular environment. % (was .4) updated Gerry March 20 2007\r
-\doublerulesep 1.8pt % Space between adjacent rules in array or tabular env.\r
-\r
-\tabbingsep \labelsep % Space used by the \' command. (See LaTeX manual.)\r
-\r
-\skip\@mpfootins =\skip\footins\r
-\r
-\fboxsep =2.7pt % Space left between box and text by \fbox and \framebox.\r
-\fboxrule =.5pt % Width of rules in box made by \fbox and \framebox. % (was .4) updated Gerry March 20 2007\r
-\r
-\def\thepart{\Roman{part}} % Roman numeral part numbers.\r
-\def\thesection {\arabic{section}}\r
-\def\thesubsection {\thesection.\arabic{subsection}}\r
-%\def\thesubsubsection {\thesubsection.\arabic{subsubsection}} % GM 7/30/2002\r
-%\def\theparagraph {\thesubsubsection.\arabic{paragraph}} % GM 7/30/2002\r
-\def\thesubparagraph {\theparagraph.\arabic{subparagraph}}\r
-\r
-\def\@pnumwidth{1.55em}\r
-\def\@tocrmarg {2.55em}\r
-\def\@dotsep{4.5}\r
-\setcounter{tocdepth}{3}\r
-\r
-%\def\tableofcontents{\@latexerr{\tableofcontents: Tables of contents are not\r
-% allowed in the `acmconf' document style.}\@eha}\r
-\r
-\def\tableofcontents{\ClassError{%\r
- \string\tableofcontents\space is not allowed in the `acmconf' document % January 2008\r
- style}\@eha}\r
-\r
-\def\l@part#1#2{\addpenalty{\@secpenalty}\r
- \addvspace{2.25em plus 1pt} % space above part line\r
- \begingroup\r
- \@tempdima 3em % width of box holding part number, used by\r
- \parindent \z@ \rightskip \@pnumwidth %% \numberline\r
- \parfillskip -\@pnumwidth\r
- {\large \bf % set line in \large boldface\r
- \leavevmode % TeX command to enter horizontal mode.\r
- #1\hfil \hbox to\@pnumwidth{\hss #2}}\par\r
- \nobreak % Never break after part entry\r
- \endgroup}\r
-\r
-\def\l@section#1#2{\addpenalty{\@secpenalty} % good place for page break\r
- \addvspace{1.0em plus 1pt} % space above toc entry\r
- \@tempdima 1.5em % width of box holding section number\r
- \begingroup\r
- \parindent \z@ \rightskip \@pnumwidth\r
- \parfillskip -\@pnumwidth\r
- \bf % Boldface.\r
- \leavevmode % TeX command to enter horizontal mode.\r
- \advance\leftskip\@tempdima %% added 5 Feb 88 to conform to\r
- \hskip -\leftskip %% 25 Jan 88 change to \numberline\r
- #1\nobreak\hfil \nobreak\hbox to\@pnumwidth{\hss #2}\par\r
- \endgroup}\r
-\r
-\r
-\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}\r
-\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}\r
-\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}\r
-\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}\r
-\r
-%\def\listoffigures{\@latexerr{\listoffigures: Lists of figures are not\r
-% allowed in the `acmconf' document style.}\@eha}\r
-\r
-\def\listoffigures{\ClassError{%\r
- \string\listoffigures\space is not allowed in the `acmconf' document % January 2008\r
- style}\@eha}\r
-\r
-\def\l@figure{\@dottedtocline{1}{1.5em}{2.3em}}\r
-\r
-%\def\listoftables{\@latexerr{\listoftables: Lists of tables are not\r
-% allowed in the `acmconf' document style.}\@eha}\r
-%\let\l@table\l@figure\r
-\r
-\def\listoftables{\ClassError{%\r
- \string\listoftables\space is not allowed in the `acmconf' document % January 2008\r
- style}\@eha}\r
- \let\l@table\l@figure\r
-\r
-\def\footnoterule{\kern-3\p@\r
- \hrule width .5\columnwidth % (was .4) updated Gerry March 20 2007\r
- \kern 2.6\p@} % The \hrule has default height of .4pt % (was .4) updated Gerry March 20 2007\r
-% ------\r
-\long\def\@makefntext#1{\noindent \r
-%\hbox to .5em{\hss$^{\@thefnmark}$}#1} % original\r
-\hbox to .5em{\hss\textsuperscript{\@thefnmark}}#1} % C. Clifton / GM Oct. 2nd. 2002\r
-% -------\r
-\r
-\long\def\@maketntext#1{\noindent\r
-#1}\r
-\r
-\long\def\@maketitlenotetext#1#2{\noindent\r
- \hbox to 1.8em{\hss$^{#1}$}#2}\r
-\r
-\setcounter{topnumber}{2}\r
-\def\topfraction{.7}\r
-\setcounter{bottomnumber}{1}\r
-\def\bottomfraction{.3}\r
-\setcounter{totalnumber}{3}\r
-\def\textfraction{.2}\r
-\def\floatpagefraction{.5}\r
-\setcounter{dbltopnumber}{2}\r
-\def\dbltopfraction{.7}\r
-\def\dblfloatpagefraction{.5}\r
-\r
-%\r
-\long\def\@makecaption#1#2{\r
- \vskip \baselineskip\r
- \setbox\@tempboxa\hbox{\textbf{#1: #2}}\r
- \ifdim \wd\@tempboxa >\hsize % IF longer than one line:\r
- \textbf{#1: #2}\par % THEN set as ordinary paragraph.\r
- \else % ELSE center.\r
- \hbox to\hsize{\hfil\box\@tempboxa\hfil}\par\r
- \fi}\r
-\r
-%\r
-\r
-\long\def\@makecaption#1#2{\r
- \vskip 10pt\r
- \setbox\@tempboxa\hbox{\textbf{#1: #2}}\r
- \ifdim \wd\@tempboxa >\hsize % IF longer than one line:\r
- \textbf{#1: #2}\par % THEN set as ordinary paragraph.\r
- \else % ELSE center.\r
- \hbox to\hsize{\hfil\box\@tempboxa\hfil}\r
- \fi}\r
-\r
-\@ifundefined{figure}{\newcounter {figure}} % this is for LaTeX2e\r
-\r
-\def\fps@figure{tbp}\r
-\def\ftype@figure{1}\r
-\def\ext@figure{lof}\r
-\def\fnum@figure{Figure \thefigure}\r
-\def\figure{\@float{figure}}\r
-%\let\endfigure\end@float\r
-\def\endfigure{\end@float} % Gerry January 2008\r
-\@namedef{figure*}{\@dblfloat{figure}}\r
-\@namedef{endfigure*}{\end@dblfloat}\r
-\r
-\@ifundefined{table}{\newcounter {table}} % this is for LaTeX2e\r
-\r
-\def\fps@table{tbp}\r
-\def\ftype@table{2}\r
-\def\ext@table{lot}\r
-\def\fnum@table{Table \thetable}\r
-\def\table{\@float{table}}\r
-%\let\endtable\end@float\r
-\def\endtable{\end@float} % Gerry January 2008\r
-\@namedef{table*}{\@dblfloat{table}}\r
-\@namedef{endtable*}{\end@dblfloat}\r
-\r
-\newtoks\titleboxnotes\r
-\newcount\titleboxnoteflag\r
-\r
-\def\maketitle{\par\r
- \begingroup\r
- \def\thefootnote{\fnsymbol{footnote}}\r
- \def\@makefnmark{\hbox\r
- to 0pt{$^{\@thefnmark}$\hss}}\r
- \twocolumn[\@maketitle]\r
-\@thanks\r
- \endgroup\r
- \setcounter{footnote}{0}\r
- \let\maketitle\relax\r
- \let\@maketitle\relax\r
- \gdef\@thanks{}\gdef\@author{}\gdef\@title{}\gdef\@subtitle{}\let\thanks\relax\r
- \@copyrightspace}\r
-\r
-%% CHANGES ON NEXT LINES\r
-\newif\if@ll % to record which version of LaTeX is in use\r
-\r
-\expandafter\ifx\csname LaTeXe\endcsname\relax % LaTeX2.09 is used\r
-\else% LaTeX2e is used, so set ll to true\r
-\global\@lltrue\r
-\fi\r
-\r
-\if@ll\r
- \NeedsTeXFormat{LaTeX2e}\r
- \ProvidesClass{sig-alternate} [2012/05/23 - V2.5 - based on acmproc.cls V1.3 <Nov. 30 '99>]\r
- \RequirePackage{latexsym}% QUERY: are these two really needed?\r
- \let\dooptions\ProcessOptions\r
-\else\r
- \let\dooptions\@options\r
-\fi\r
-%% END CHANGES\r
-\r
-\def\@height{height}\r
-\def\@width{width}\r
-\def\@minus{minus}\r
-\def\@plus{plus}\r
-\def\hb@xt@{\hbox to}\r
-\newif\if@faircopy\r
-\@faircopyfalse\r
-\def\ds@faircopy{\@faircopytrue}\r
-\r
-\def\ds@preprint{\@faircopyfalse}\r
-\r
-\@twosidetrue\r
-\@mparswitchtrue\r
-\def\ds@draft{\overfullrule 5\p@}\r
-%% CHANGE ON NEXT LINE\r
-\dooptions\r
-\r
-\lineskip \p@\r
-\normallineskip \p@\r
-\def\baselinestretch{1}\r
-\def\@ptsize{0} %needed for amssymbols.sty\r
-\r
-%% CHANGES ON NEXT LINES\r
-\if@ll% allow use of old-style font change commands in LaTeX2e\r
-\@maxdepth\maxdepth\r
-%\r
-\DeclareOldFontCommand{\rm}{\ninept\rmfamily}{\mathrm}\r
-\DeclareOldFontCommand{\sf}{\normalfont\sffamily}{\mathsf}\r
-\DeclareOldFontCommand{\tt}{\normalfont\ttfamily}{\mathtt}\r
-\DeclareOldFontCommand{\bf}{\normalfont\bfseries}{\mathbf}\r
-\DeclareOldFontCommand{\it}{\normalfont\itshape}{\mathit}\r
-\DeclareOldFontCommand{\sl}{\normalfont\slshape}{\@nomath\sl}\r
-\DeclareOldFontCommand{\sc}{\normalfont\scshape}{\@nomath\sc}\r
-\DeclareRobustCommand*{\cal}{\@fontswitch{\relax}{\mathcal}}\r
-\DeclareRobustCommand*{\mit}{\@fontswitch{\relax}{\mathnormal}}\r
-\fi\r
-%\r
-\if@ll\r
- \renewcommand{\rmdefault}{cmr} % was 'ttm'\r
-% Note! I have also found 'mvr' to work ESPECIALLY well.\r
-% Gerry - October 1999\r
-% You may need to change your LV1times.fd file so that sc is\r
-% mapped to cmcsc - -for smallcaps -- that is if you decide\r
-% to change {cmr} to {times} above. (Not recommended)\r
- \renewcommand{\@ptsize}{}\r
- \renewcommand{\normalsize}{%\r
- \@setfontsize\normalsize\@ixpt{10.5\p@}%\ninept%\r
- \abovedisplayskip 6\p@ \@plus2\p@ \@minus\p@\r
- \belowdisplayskip \abovedisplayskip\r
- \abovedisplayshortskip 6\p@ \@minus 3\p@\r
- \belowdisplayshortskip 6\p@ \@minus 3\p@\r
- \let\@listi\@listI\r
- }\r
-\else\r
- \def\@normalsize{%changed next to 9 from 10\r
- \@setsize\normalsize{9\p@}\ixpt\@ixpt\r
- \abovedisplayskip 6\p@ \@plus2\p@ \@minus\p@\r
- \belowdisplayskip \abovedisplayskip\r
- \abovedisplayshortskip 6\p@ \@minus 3\p@\r
- \belowdisplayshortskip 6\p@ \@minus 3\p@\r
- \let\@listi\@listI\r
- }%\r
-\fi\r
-\if@ll\r
- \newcommand\scriptsize{\@setfontsize\scriptsize\@viipt{8\p@}}\r
- \newcommand\tiny{\@setfontsize\tiny\@vpt{6\p@}}\r
- \newcommand\large{\@setfontsize\large\@xiipt{14\p@}}\r
- \newcommand\Large{\@setfontsize\Large\@xivpt{18\p@}}\r
- \newcommand\LARGE{\@setfontsize\LARGE\@xviipt{20\p@}}\r
- \newcommand\huge{\@setfontsize\huge\@xxpt{25\p@}}\r
- \newcommand\Huge{\@setfontsize\Huge\@xxvpt{30\p@}}\r
-\else\r
- \def\scriptsize{\@setsize\scriptsize{8\p@}\viipt\@viipt}\r
- \def\tiny{\@setsize\tiny{6\p@}\vpt\@vpt}\r
- \def\large{\@setsize\large{14\p@}\xiipt\@xiipt}\r
- \def\Large{\@setsize\Large{18\p@}\xivpt\@xivpt}\r
- \def\LARGE{\@setsize\LARGE{20\p@}\xviipt\@xviipt}\r
- \def\huge{\@setsize\huge{25\p@}\xxpt\@xxpt}\r
- \def\Huge{\@setsize\Huge{30\p@}\xxvpt\@xxvpt}\r
-\fi\r
-\normalsize\r
-\r
-% make aubox hsize/number of authors up to 3, less gutter\r
-% then showbox gutter showbox gutter showbox -- GKMT Aug 99\r
-\newbox\@acmtitlebox\r
-\def\@maketitle{\newpage\r
- \null\r
- \setbox\@acmtitlebox\vbox{%\r
-\baselineskip 20pt\r
-\vskip 2em % Vertical space above title.\r
- \begin{center}\r
- {\ttlfnt \@title\par} % Title set in 18pt Helvetica (Arial) bold size.\r
- \vskip 1.5em % Vertical space after title.\r
-%This should be the subtitle.\r
-{\subttlfnt \the\subtitletext\par}\vskip 1.25em%\fi\r
- {\baselineskip 16pt\aufnt % each author set in \12 pt Arial, in a\r
- \lineskip .5em % tabular environment\r
- \begin{tabular}[t]{c}\@author\r
- \end{tabular}\par}\r
- \vskip 1.5em % Vertical space after author.\r
- \end{center}}\r
- \dimen0=\ht\@acmtitlebox\r
- \advance\dimen0 by -12.75pc\relax % Increased space for title box -- KBT\r
- \unvbox\@acmtitlebox\r
- \ifdim\dimen0<0.0pt\relax\vskip-\dimen0\fi}\r
-\r
-\r
-\newcount\titlenotecount\r
-\global\titlenotecount=0\r
-\newtoks\tntoks\r
-\newtoks\tntokstwo\r
-\newtoks\tntoksthree\r
-\newtoks\tntoksfour\r
-\newtoks\tntoksfive\r
-\r
-\def\abstract{\r
-\ifnum\titlenotecount>0 % was =1\r
- \insert\footins{%\r
- \reset@font\footnotesize\r
- \interlinepenalty\interfootnotelinepenalty\r
- \splittopskip\footnotesep\r
- \splitmaxdepth \dp\strutbox \floatingpenalty \@MM\r
- \hsize\columnwidth \@parboxrestore\r
- \protected@edef\@currentlabel{%\r
- }%\r
- \color@begingroup\r
-\ifnum\titlenotecount=1\r
- \@maketntext{%\r
- \raisebox{4pt}{$\ast$}\rule\z@\footnotesep\ignorespaces\the\tntoks\@finalstrut\strutbox}%\r
-\fi\r
-\ifnum\titlenotecount=2\r
- \@maketntext{%\r
- \raisebox{4pt}{$\ast$}\rule\z@\footnotesep\ignorespaces\the\tntoks\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\dagger$}\rule\z@\footnotesep\ignorespaces\the\tntokstwo\@finalstrut\strutbox}%\r
-\fi\r
-\ifnum\titlenotecount=3\r
- \@maketntext{%\r
- \raisebox{4pt}{$\ast$}\rule\z@\footnotesep\ignorespaces\the\tntoks\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\dagger$}\rule\z@\footnotesep\ignorespaces\the\tntokstwo\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\ddagger$}\rule\z@\footnotesep\ignorespaces\the\tntoksthree\@finalstrut\strutbox}%\r
-\fi\r
-\ifnum\titlenotecount=4\r
- \@maketntext{%\r
- \raisebox{4pt}{$\ast$}\rule\z@\footnotesep\ignorespaces\the\tntoks\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\dagger$}\rule\z@\footnotesep\ignorespaces\the\tntokstwo\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\ddagger$}\rule\z@\footnotesep\ignorespaces\the\tntoksthree\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\S$}\rule\z@\footnotesep\ignorespaces\the\tntoksfour\@finalstrut\strutbox}%\r
-\fi\r
-\ifnum\titlenotecount=5\r
- \@maketntext{%\r
- \raisebox{4pt}{$\ast$}\rule\z@\footnotesep\ignorespaces\the\tntoks\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\dagger$}\rule\z@\footnotesep\ignorespaces\the\tntokstwo\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\ddagger$}\rule\z@\footnotesep\ignorespaces\the\tntoksthree\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\S$}\rule\z@\footnotesep\ignorespaces\the\tntoksfour\par\@finalstrut\strutbox}%\r
-\@maketntext{%\r
- \raisebox{4pt}{$\P$}\rule\z@\footnotesep\ignorespaces\the\tntoksfive\@finalstrut\strutbox}%\r
-\fi\r
- \color@endgroup} %g}\r
-\fi\r
-\setcounter{footnote}{0}\r
-\section*{ABSTRACT}\normalsize%\ninept\r
-}\r
-\r
-\def\endabstract{\if@twocolumn\else\endquotation\fi}\r
-\r
-\def\keywords{\if@twocolumn\r
-\section*{Keywords}\r
-\else \small\r
-\quotation\r
-\fi}\r
-\r
-\def\terms{\if@twocolumn\r
-\section*{General Terms}\r
-\else \small\r
-\quotation\r
-\fi}\r
-\r
-% -- Classification needs to be a bit smart due to optionals - Gerry/Georgia November 2nd. 1999\r
-\newcount\catcount\r
-\global\catcount=1\r
-\r
-\def\category#1#2#3{%\r
-\ifnum\catcount=1\r
-\section*{Categories and Subject Descriptors}\r
-\advance\catcount by 1\else{\unskip; }\fi\r
- \@ifnextchar [{\@category{#1}{#2}{#3}}{\@category{#1}{#2}{#3}[]}%\r
-}\r
-\r
-\def\@category#1#2#3[#4]{%\r
- \begingroup\r
- \let\and\relax\r
- #1 [\textbf{#2}]%\r
- \if!#4!%\r
- \if!#3!\else : #3\fi\r
- \else\r
- :\space\r
- \if!#3!\else #3\kern\z@---\hskip\z@\fi\r
- \textit{#4}%\r
- \fi\r
- \endgroup\r
-}\r
-%\r
-\r
-%%% This section (written by KBT) handles the 1" box in the lower left\r
-%%% corner of the left column of the first page by creating a picture,\r
-%%% and inserting the predefined string at the bottom (with a negative\r
-%%% displacement to offset the space allocated for a non-existent\r
-%%% caption).\r
-%%%\r
-\newtoks\copyrightnotice\r
-\def\ftype@copyrightbox{8}\r
-\def\@copyrightspace{\r
-\@float{copyrightbox}[b]\r
-\begin{center}\r
-\setlength{\unitlength}{1pc}\r
-\begin{picture}(20,6) %Space for copyright notice\r
-\put(0,-0.95){\crnotice{\@toappear}}\r
-\end{picture}\r
-\end{center}\r
-\end@float}\r
-\r
-\def\@toappear{} % Default setting blank - commands below change this.\r
-\long\def\toappear#1{\def\@toappear{\parbox[b]{20pc}{\baselineskip 9pt#1}}}\r
-\def\toappearbox#1{\def\@toappear{\raisebox{5pt}{\framebox[20pc]{\parbox[b]{19pc}{#1}}}}}\r
-\r
-\newtoks\conf\r
-\newtoks\confinfo\r
-\def\conferenceinfo#1#2{\global\conf={#1}\global\confinfo{#2}}\r
-\r
-\r
-%\def\marginpar{\@latexerr{The \marginpar command is not allowed in the\r
-% `acmconf' document style.}\@eha}\r
-\r
-\def\marginpar{\ClassError{%\r
- \string\marginpar\space is not allowed in the `acmconf' document % January 2008\r
- style}\@eha}\r
-\r
-\mark{{}{}} % Initializes TeX's marks\r
-\r
-\def\today{\ifcase\month\or\r
- January\or February\or March\or April\or May\or June\or\r
- July\or August\or September\or October\or November\or December\fi\r
- \space\number\day, \number\year}\r
-\r
-\def\@begintheorem#1#2{%\r
- \parskip 0pt % GM July 2000 (for tighter spacing)\r
- \trivlist\r
- \item[%\r
- \hskip 10\p@\r
- \hskip \labelsep\r
- {{\sc #1}\hskip 5\p@\relax#2.}%\r
- ]\r
- \it\r
-}\r
-\def\@opargbegintheorem#1#2#3{%\r
- \parskip 0pt % GM July 2000 (for tighter spacing)\r
- \trivlist\r
- \item[%\r
- \hskip 10\p@\r
- \hskip \labelsep\r
- {\sc #1\ #2\ % This mod by Gerry to enumerate corollaries\r
- \setbox\@tempboxa\hbox{(#3)} % and bracket the 'corollary title'\r
- \ifdim \wd\@tempboxa>\z@ % and retain the correct numbering of e.g. theorems\r
- \hskip 5\p@\relax % if they occur 'around' said corollaries.\r
- \box\@tempboxa % Gerry - Nov. 1999.\r
- \fi.}%\r
- ]\r
- \it\r
-}\r
-\newif\if@qeded\r
-\global\@qededfalse\r
-\r
-% -- original\r
-%\def\proof{%\r
-% \vspace{-\parskip} % GM July 2000 (for tighter spacing)\r
-% \global\@qededfalse\r
-% \@ifnextchar[{\@xproof}{\@proof}%\r
-%}\r
-% -- end of original\r
-\r
-% (JSS) Fix for vertical spacing bug - Gerry Murray July 30th. 2002\r
-\def\proof{%\r
-\vspace{-\lastskip}\vspace{-\parsep}\penalty-51%\r
-\global\@qededfalse\r
-\@ifnextchar[{\@xproof}{\@proof}%\r
-}\r
-\r
-\def\endproof{%\r
- \if@qeded\else\qed\fi\r
- \endtrivlist\r
-}\r
-\def\@proof{%\r
- \trivlist\r
- \item[%\r
- \hskip 10\p@\r
- \hskip \labelsep\r
- {\sc Proof.}%\r
- ]\r
- \ignorespaces\r
-}\r
-\def\@xproof[#1]{%\r
- \trivlist\r
- \item[\hskip 10\p@\hskip \labelsep{\sc Proof #1.}]%\r
- \ignorespaces\r
-}\r
-\def\qed{%\r
- \unskip\r
- \kern 10\p@\r
- \begingroup\r
- \unitlength\p@\r
- \linethickness{.4\p@}%\r
- \framebox(6,6){}%\r
- \endgroup\r
- \global\@qededtrue\r
-}\r
-\r
-\def\newdef#1#2{%\r
- \expandafter\@ifdefinable\csname #1\endcsname\r
- {\@definecounter{#1}%\r
- \expandafter\xdef\csname the#1\endcsname{\@thmcounter{#1}}%\r
- \global\@namedef{#1}{\@defthm{#1}{#2}}%\r
- \global\@namedef{end#1}{\@endtheorem}%\r
- }%\r
-}\r
-\def\@defthm#1#2{%\r
- \refstepcounter{#1}%\r
- \@ifnextchar[{\@ydefthm{#1}{#2}}{\@xdefthm{#1}{#2}}%\r
-}\r
-\def\@xdefthm#1#2{%\r
- \@begindef{#2}{\csname the#1\endcsname}%\r
- \ignorespaces\r
-}\r
-\def\@ydefthm#1#2[#3]{%\r
- \trivlist\r
- \item[%\r
- \hskip 10\p@\r
- \hskip \labelsep\r
- {\it #2%\r
-% \savebox\@tempboxa{#3}%\r
- \saveb@x\@tempboxa{#3}% % January 2008\r
- \ifdim \wd\@tempboxa>\z@\r
- \ \box\@tempboxa\r
- \fi.%\r
- }]%\r
- \ignorespaces\r
-}\r
-\def\@begindef#1#2{%\r
- \trivlist\r
- \item[%\r
- \hskip 10\p@\r
- \hskip \labelsep\r
- {\it #1\ \rm #2.}%\r
- ]%\r
-}\r
-\def\theequation{\arabic{equation}}\r
-\r
-\newcounter{part}\r
-\newcounter{section}\r
-\newcounter{subsection}[section]\r
-\newcounter{subsubsection}[subsection]\r
-\newcounter{paragraph}[subsubsection]\r
-\def\thepart{\Roman{part}}\r
-\def\thesection{\arabic{section}}\r
-\def\thesubsection{\thesection.\arabic{subsection}}\r
-\def\thesubsubsection{\thesubsection.\arabic{subsubsection}} %removed \subsecfnt 29 July 2002 gkmt\r
-\def\theparagraph{\thesubsubsection.\arabic{paragraph}} %removed \subsecfnt 29 July 2002 gkmt\r
-\newif\if@uchead\r
-\@ucheadfalse\r
-\r
-%% CHANGES: NEW NOTE\r
-%% NOTE: OK to use old-style font commands below, since they were\r
-%% suitably redefined for LaTeX2e\r
-%% END CHANGES\r
-\setcounter{secnumdepth}{3}\r
-\def\part{%\r
- \@startsection{part}{9}{\z@}{-10\p@ \@plus -4\p@ \@minus -2\p@}\r
- {4\p@}{\normalsize\@ucheadtrue}%\r
-}\r
-\def\section{%\r
- \@startsection{section}{1}{\z@}{-10\p@ \@plus -4\p@ \@minus -2\p@}% GM\r
- {4\p@}{\baselineskip 14pt\secfnt\@ucheadtrue}%\r
-}\r
-\r
-\def\subsection{%\r
- \@startsection{subsection}{2}{\z@}{-8\p@ \@plus -2\p@ \@minus -\p@}\r
- {4\p@}{\secfnt}%\r
-}\r
-\def\subsubsection{%\r
- \@startsection{subsubsection}{3}{\z@}{-8\p@ \@plus -2\p@ \@minus -\p@}%\r
- {4\p@}{\subsecfnt}%\r
-}\r
-%\def\paragraph{%\r
-% \vskip 12pt\@startsection{paragraph}{3}{\z@}{6\p@ \@plus \p@}% original\r
-% {-5\p@}{\subsecfnt}%\r
-%}\r
-% If one wants sections, subsections and subsubsections numbered,\r
-% but not paragraphs, one usually sets secnumepth to 3.\r
-% For that, the "depth" of paragraphs must be given correctly\r
-% in the definition (``4'' instead of ``3'' as second argument\r
-% of @startsection):\r
-\def\paragraph{%\r
- \vskip 12pt\@startsection{paragraph}{4}{\z@}{6\p@ \@plus \p@}% % GM and Wolfgang May - 11/30/06\r
- {-5\p@}{\subsecfnt}%\r
-}\r
-\let\@period=.\r
-\def\@startsection#1#2#3#4#5#6{%\r
- \if@noskipsec %gkmt, 11 aug 99\r
- \global\let\@period\@empty\r
- \leavevmode\r
- \global\let\@period.%\r
- \fi\r
- \par %\r
- \@tempskipa #4\relax\r
- \@afterindenttrue\r
- \ifdim \@tempskipa <\z@\r
- \@tempskipa -\@tempskipa\r
- \@afterindentfalse\r
- \fi\r
- \if@nobreak\r
- \everypar{}%\r
- \else\r
- \addpenalty\@secpenalty\r
- \addvspace\@tempskipa\r
- \fi\r
-\parskip=0pt % GM July 2000 (non numbered) section heads\r
- \@ifstar\r
- {\@ssect{#3}{#4}{#5}{#6}}\r
- {\@dblarg{\@sect{#1}{#2}{#3}{#4}{#5}{#6}}}%\r
-}\r
-\def\@sect#1#2#3#4#5#6[#7]#8{%\r
- \ifnum #2>\c@secnumdepth\r
- \let\@svsec\@empty\r
- \else\r
- \refstepcounter{#1}%\r
- \edef\@svsec{%\r
- \begingroup\r
- %\ifnum#2>2 \noexpand\rm \fi % changed to next 29 July 2002 gkmt\r
- \ifnum#2>2 \noexpand#6 \fi\r
- \csname the#1\endcsname\r
- \endgroup\r
- \ifnum #2=1\relax .\fi\r
- \hskip 1em\r
- }%\r
- \fi\r
- \@tempskipa #5\relax\r
- \ifdim \@tempskipa>\z@\r
- \begingroup\r
- #6\relax\r
- \@hangfrom{\hskip #3\relax\@svsec}%\r
- \begingroup\r
- \interlinepenalty \@M\r
- \if@uchead\r
- \uppercase{#8}%\r
- \else\r
- #8%\r
- \fi\r
- \par\r
- \endgroup\r
- \endgroup\r
- \csname #1mark\endcsname{#7}%\r
- \vskip -12pt %gkmt, 11 aug 99 and GM July 2000 (was -14) - numbered section head spacing\r
-\addcontentsline{toc}{#1}{%\r
- \ifnum #2>\c@secnumdepth \else\r
- \protect\numberline{\csname the#1\endcsname}%\r
- \fi\r
- #7%\r
- }%\r
- \else\r
- \def\@svsechd{%\r
- #6%\r
- \hskip #3\relax\r
- \@svsec\r
- \if@uchead\r
- \uppercase{#8}%\r
- \else\r
- #8%\r
- \fi\r
- \csname #1mark\endcsname{#7}%\r
- \addcontentsline{toc}{#1}{%\r
- \ifnum #2>\c@secnumdepth \else\r
- \protect\numberline{\csname the#1\endcsname}%\r
- \fi\r
- #7%\r
- }%\r
- }%\r
- \fi\r
- \@xsect{#5}\hskip 1pt\r
- \par\r
-}\r
-\def\@xsect#1{%\r
- \@tempskipa #1\relax\r
- \ifdim \@tempskipa>\z@\r
- \par\r
- \nobreak\r
- \vskip \@tempskipa\r
- \@afterheading\r
- \else\r
- \global\@nobreakfalse\r
- \global\@noskipsectrue\r
- \everypar{%\r
- \if@noskipsec\r
- \global\@noskipsecfalse\r
- \clubpenalty\@M\r
- \hskip -\parindent\r
- \begingroup\r
- \@svsechd\r
- \@period\r
- \endgroup\r
- \unskip\r
- \@tempskipa #1\relax\r
- \hskip -\@tempskipa\r
- \else\r
- \clubpenalty \@clubpenalty\r
- \everypar{}%\r
- \fi\r
- }%\r
- \fi\r
- \ignorespaces\r
-}\r
-\def\@trivlist{%\r
- \@topsepadd\topsep\r
- \if@noskipsec\r
- \global\let\@period\@empty\r
- \leavevmode\r
- \global\let\@period.%\r
- \fi\r
- \ifvmode\r
- \advance\@topsepadd\partopsep\r
- \else\r
- \unskip\r
- \par\r
- \fi\r
- \if@inlabel\r
- \@noparitemtrue\r
- \@noparlisttrue\r
- \else\r
- \@noparlistfalse\r
- \@topsep\@topsepadd\r
- \fi\r
- \advance\@topsep \parskip\r
- \leftskip\z@skip\r
- \rightskip\@rightskip\r
- \parfillskip\@flushglue\r
- \@setpar{\if@newlist\else{\@@par}\fi}\r
- \global\@newlisttrue\r
- \@outerparskip\parskip\r
-}\r
-\r
-%%% Actually, 'abbrev' works just fine as the default\r
-%%% Bibliography style.\r
-\r
-\typeout{Using 'Abbrev' bibliography style}\r
-\newcommand\bibyear[2]{%\r
- \unskip\quad\ignorespaces#1\unskip\r
- \if#2..\quad \else \quad#2 \fi\r
-}\r
-\newcommand{\bibemph}[1]{{\em#1}}\r
-\newcommand{\bibemphic}[1]{{\em#1\/}}\r
-\newcommand{\bibsc}[1]{{\sc#1}}\r
-\def\@normalcite{%\r
- \def\@cite##1##2{[##1\if@tempswa , ##2\fi]}%\r
-}\r
-\def\@citeNB{%\r
- \def\@cite##1##2{##1\if@tempswa , ##2\fi}%\r
-}\r
-\def\@citeRB{%\r
- \def\@cite##1##2{##1\if@tempswa , ##2\fi]}%\r
-}\r
-\def\start@cite#1#2{%\r
- \edef\citeauthoryear##1##2##3{%\r
- ###1%\r
- \ifnum#2=\z@ \else\ ###2\fi\r
- }%\r
- \ifnum#1=\thr@@\r
- \let\@@cite\@citeyear\r
- \else\r
- \let\@@cite\@citenormal\r
- \fi\r
- \@ifstar{\@citeNB\@@cite}{\@normalcite\@@cite}%\r
-}\r
-%\def\cite{\start@cite23}\r
-\DeclareRobustCommand\cite{\start@cite23} % January 2008\r
-\def\citeNP{\cite*} % No Parentheses e.g. 5\r
-%\def\citeA{\start@cite10}\r
-\DeclareRobustCommand\citeA{\start@cite10} % January 2008\r
-\def\citeANP{\citeA*}\r
-%\def\shortcite{\start@cite23} \r
-\DeclareRobustCommand\shortcite{\start@cite23} % January 2008\r
-\def\shortciteNP{\shortcite*}\r
-%\def\shortciteA{\start@cite20}\r
-\DeclareRobustCommand\shortciteA{\start@cite20} % January 2008\r
-\def\shortciteANP{\shortciteA*}\r
-%\def\citeyear{\start@cite30}\r
-\DeclareRobustCommand\citeyear{\start@cite30} % January 2008\r
-\def\citeyearNP{\citeyear*}\r
-%\def\citeN{%\r
-\DeclareRobustCommand\citeN{% % January 2008\r
- \@citeRB\r
- \def\citeauthoryear##1##2##3{##1\ [##3%\r
- \def\reserved@a{##1}%\r
- \def\citeauthoryear####1####2####3{%\r
- \def\reserved@b{####1}%\r
- \ifx\reserved@a\reserved@b\r
- ####3%\r
- \else\r
- \errmessage{Package acmart Error: author mismatch\r
- in \string\citeN^^J^^J%\r
- See the acmart package documentation for explanation}%\r
- \fi\r
- }%\r
- }%\r
- \@ifstar\@citeyear\@citeyear\r
-}\r
-%\def\shortciteN{%\r
-\DeclareRobustCommand\shortciteN{% % January 2008\r
- \@citeRB\r
- \def\citeauthoryear##1##2##3{##2\ [##3%\r
- \def\reserved@a{##2}%\r
- \def\citeauthoryear####1####2####3{%\r
- \def\reserved@b{####2}%\r
- \ifx\reserved@a\reserved@b\r
- ####3%\r
- \else\r
- \errmessage{Package acmart Error: author mismatch\r
- in \string\shortciteN^^J^^J%\r
- See the acmart package documentation for explanation}%\r
- \fi\r
- }%\r
- }%\r
- \@ifstar\@citeyear\@citeyear % GM July 2000\r
-}\r
-\r
-\def\@citenormal{%\r
- \@ifnextchar [{\@tempswatrue\@citex;}%\r
-% original {\@tempswafalse\@citex,[]}% was ; Gerry 2/24/00\r
-{\@tempswafalse\@citex[]}% % GERRY FIX FOR BABEL 3/20/2009\r
-}\r
-\r
-\def\@citeyear{%\r
- \@ifnextchar [{\@tempswatrue\@citex,}%\r
-% original {\@tempswafalse\@citex,[]}%\r
-{\@tempswafalse\@citex[]}% % GERRY FIX FOR BABEL 3/20/2009\r
-}\r
-\r
-\def\@citex#1[#2]#3{%\r
- \let\@citea\@empty\r
- \@cite{%\r
- \@for\@citeb:=#3\do{%\r
- \@citea\r
-% original \def\@citea{#1 }%\r
- \def\@citea{#1, }% % GERRY FIX FOR BABEL 3/20/2009 -- SO THAT YOU GET [1, 2] IN THE BODY TEXT\r
- \edef\@citeb{\expandafter\@iden\@citeb}%\r
- \if@filesw\r
- \immediate\write\@auxout{\string\citation{\@citeb}}%\r
- \fi\r
- \@ifundefined{b@\@citeb}{%\r
- {\bf ?}%\r
- \@warning{%\r
- Citation `\@citeb' on page \thepage\space undefined%\r
- }%\r
- }%\r
- {\csname b@\@citeb\endcsname}%\r
- }%\r
- }{#2}%\r
-}\r
-%\let\@biblabel\@gobble % Dec. 2008 - Gerry\r
-% ----\r
-\def\@biblabelnum#1{[#1]} % Gerry's solution #1 - for Natbib -- April 2009\r
-\let\@biblabel=\@biblabelnum % Gerry's solution #1 - for Natbib -- April 2009\r
-\def\newblock{\relax} % Gerry Dec. 2008\r
-% ---\r
-\newdimen\bibindent\r
-\setcounter{enumi}{1}\r
-\bibindent=0em\r
-\def\thebibliography#1{% \r
-\ifnum\addauflag=0\addauthorsection\global\addauflag=1\fi\r
- \section[References]{% <=== OPTIONAL ARGUMENT ADDED HERE\r
- {References} % was uppercased but this affects pdf bookmarks (SP/GM October 2004)\r
- {\vskip -9pt plus 1pt} % GM Nov. 2006 / GM July 2000 (for somewhat tighter spacing) \r
- \@mkboth{{\refname}}{{\refname}}%\r
- }%\r
- \list{[\arabic{enumi}]}{%\r
- \settowidth\labelwidth{[#1]}%\r
- \leftmargin\labelwidth\r
- \advance\leftmargin\labelsep\r
- \advance\leftmargin\bibindent\r
- \parsep=0pt\itemsep=1pt % GM July 2000\r
- \itemindent -\bibindent\r
- \listparindent \itemindent\r
- \usecounter{enumi}\r
- }%\r
- \let\newblock\@empty\r
- \raggedright % GM July 2000\r
- \sloppy\r
- \sfcode`\.=1000\relax\r
-}\r
-\r
-\r
-\gdef\balancecolumns\r
-{\vfill\eject\r
-\global\@colht=\textheight\r
-\global\ht\@cclv=\textheight\r
-}\r
-\r
-\newcount\colcntr\r
-\global\colcntr=0\r
-%\newbox\savebox\r
-\newbox\saveb@x % January 2008\r
-\r
-\gdef \@makecol {%\r
-\global\advance\colcntr by 1\r
-\ifnum\colcntr>2 \global\colcntr=1\fi\r
- \ifvoid\footins\r
- \setbox\@outputbox \box\@cclv\r
- \else\r
- \setbox\@outputbox \vbox{%\r
-\boxmaxdepth \@maxdepth\r
- \@tempdima\dp\@cclv\r
- \unvbox \@cclv\r
- \vskip-\@tempdima\r
- \vskip \skip\footins\r
- \color@begingroup\r
- \normalcolor\r
- \footnoterule\r
- \unvbox \footins\r
- \color@endgroup\r
- }%\r
- \fi\r
- \xdef\@freelist{\@freelist\@midlist}%\r
- \global \let \@midlist \@empty\r
- \@combinefloats\r
- \ifvbox\@kludgeins\r
- \@makespecialcolbox\r
- \else\r
- \setbox\@outputbox \vbox to\@colht {%\r
-\@texttop\r
- \dimen@ \dp\@outputbox\r
- \unvbox \@outputbox\r
- \vskip -\dimen@\r
- \@textbottom\r
- }%\r
- \fi\r
- \global \maxdepth \@maxdepth\r
-}\r
-\def\titlenote{\@ifnextchar[\@xtitlenote{\stepcounter\@mpfn\r
-\global\advance\titlenotecount by 1\r
-\ifnum\titlenotecount=1\r
- \raisebox{9pt}{$\ast$}\r
-\fi\r
-\ifnum\titlenotecount=2\r
- \raisebox{9pt}{$\dagger$}\r
-\fi\r
-\ifnum\titlenotecount=3\r
- \raisebox{9pt}{$\ddagger$}\r
-\fi\r
-\ifnum\titlenotecount=4\r
-\raisebox{9pt}{$\S$}\r
-\fi\r
-\ifnum\titlenotecount=5\r
-\raisebox{9pt}{$\P$}\r
-\fi\r
- \@titlenotetext\r
-}}\r
-\r
-\long\def\@titlenotetext#1{\insert\footins{%\r
-\ifnum\titlenotecount=1\global\tntoks={#1}\fi\r
-\ifnum\titlenotecount=2\global\tntokstwo={#1}\fi\r
-\ifnum\titlenotecount=3\global\tntoksthree={#1}\fi\r
-\ifnum\titlenotecount=4\global\tntoksfour={#1}\fi\r
-\ifnum\titlenotecount=5\global\tntoksfive={#1}\fi\r
- \reset@font\footnotesize\r
- \interlinepenalty\interfootnotelinepenalty\r
- \splittopskip\footnotesep\r
- \splitmaxdepth \dp\strutbox \floatingpenalty \@MM\r
- \hsize\columnwidth \@parboxrestore\r
- \protected@edef\@currentlabel{%\r
- }%\r
- \color@begingroup\r
- \color@endgroup}}\r
-\r
-%%%%%%%%%%%%%%%%%%%%%%%%%\r
-\ps@plain\r
-\baselineskip=11pt\r
-\let\thepage\relax % For NO page numbers - GM Nov. 30th. 1999 and July 2000\r
-\def\setpagenumber#1{\global\setcounter{page}{#1}}\r
-%\pagenumbering{arabic} % Arabic page numbers GM July 2000\r
-\twocolumn % Double column.\r
-\flushbottom % Even bottom -- alas, does not balance columns at end of document\r
-\pagestyle{plain}\r
-\r
-% Need Copyright Year and Copyright Data to be user definable (in .tex file).\r
-% Gerry Nov. 30th. 1999\r
-\newtoks\copyrtyr\r
-\newtoks\acmcopyr\r
-\newtoks\boilerplate\r
-\global\acmcopyr={X-XXXXX-XX-X/XX/XX} % Default - 5/11/2001 *** Gerry\r
-\global\copyrtyr={20XX} % Default - 3/3/2003 *** Gerry\r
-\def\CopyrightYear#1{\global\copyrtyr{#1}}\r
-\def\crdata#1{\global\acmcopyr{#1}}\r
-\def\permission#1{\global\boilerplate{#1}}\r
-%\r
-\global\boilerplate={Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.}\r
-\newtoks\copyrightetc\r
-\global\copyrightetc{Copyright \the\copyrtyr\ ACM \the\acmcopyr\ ...\$15.00} % Gerry changed to 15 May 2012\r
-\toappear{\the\boilerplate\par\r
-{\confname{\the\conf}} \the\confinfo\par \the\copyrightetc.}\r
-%\DeclareFixedFont{\altcrnotice}{OT1}{tmr}{m}{n}{8} % << patch needed for accenting e.g. Montreal - Gerry, May 2007\r
-%\DeclareFixedFont{\altconfname}{OT1}{tmr}{m}{it}{8} % << patch needed for accenting in italicized confname - Gerry, May 2007\r
-%\r
-%{\altconfname{{\the\conf}}} {\altcrnotice\the\confinfo\par} \the\copyrightetc.} % << Gerry, May 2007\r
-%\r
-% The following section (i.e. 3 .sty inclusions) was added in May 2007 so as to fix the problems that many\r
-% authors were having with accents. Sometimes accents would occur, but the letter-character would be of a different\r
-% font. Conversely the letter-character font would be correct but, e.g. a 'bar' would appear superimposed on the\r
-% character instead of, say, an unlaut/diaresis. Sometimes the letter-character would NOT appear at all.\r
-% Using [T1]{fontenc} outright was not an option as this caused 99% of the authors to 'produce' a Type-3 (bitmapped)\r
-% PDF file - useless for production. \r
-%\r
-% For proper (font) accenting we NEED these packages to be part of the .cls file i.e. 'ae', 'aecompl' and 'aeguil' \r
-% ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
-%% This is file `ae.sty' \r
-\def\fileversion{1.3}\r
-\def\filedate{2001/02/12}\r
-\NeedsTeXFormat{LaTeX2e}\r
-%\ProvidesPackage{ae}[\filedate\space\fileversion\space % GM\r
-% Almost European Computer Modern] % GM - keeping the log file clean(er)\r
-\newif\if@ae@slides \@ae@slidesfalse\r
-\DeclareOption{slides}{\@ae@slidestrue}\r
-\ProcessOptions\r
-\fontfamily{aer}\r
-\RequirePackage[T1]{fontenc}\r
-\if@ae@slides\r
- \renewcommand{\sfdefault}{laess}\r
- \renewcommand{\rmdefault}{laess} % no roman\r
- \renewcommand{\ttdefault}{laett}\r
-\else\r
- \renewcommand{\sfdefault}{aess}\r
- \renewcommand{\rmdefault}{aer}\r
- \renewcommand{\ttdefault}{aett}\r
-\fi\r
-\endinput\r
-%% \r
-%% End of file `ae.sty'.\r
-%\r
-%\r
-\def\fileversion{0.9}\r
-\def\filedate{1998/07/23}\r
-\NeedsTeXFormat{LaTeX2e}\r
-%\ProvidesPackage{aecompl}[\filedate\space\fileversion\space % GM\r
-%T1 Complements for AE fonts (D. Roegel)] % GM -- keeping the log file clean(er)\r
- \r
-\def\@ae@compl#1{{\fontencoding{T1}\fontfamily{cmr}\selectfont\symbol{#1}}}\r
-\def\guillemotleft{\@ae@compl{19}}\r
-\def\guillemotright{\@ae@compl{20}}\r
-\def\guilsinglleft{\@ae@compl{14}}\r
-\def\guilsinglright{\@ae@compl{15}}\r
-\def\TH{\@ae@compl{222}}\r
-\def\NG{\@ae@compl{141}}\r
-\def\ng{\@ae@compl{173}}\r
-\def\th{\@ae@compl{254}}\r
-\def\DJ{\@ae@compl{208}}\r
-\def\dj{\@ae@compl{158}}\r
-\def\DH{\@ae@compl{208}}\r
-\def\dh{\@ae@compl{240}}\r
-\def\@perthousandzero{\@ae@compl{24}}\r
-\def\textperthousand{\%\@perthousandzero}\r
-\def\textpertenthousand{\%\@perthousandzero\@perthousandzero}\r
-\endinput\r
-%\r
-%\r
-%% This is file `aeguill.sty' \r
-% This file gives french guillemets (and not guillemots!)\r
-% built with the Polish CMR fonts (default), WNCYR fonts, the LASY fonts \r
-% or with the EC fonts. \r
-% This is useful in conjunction with the ae package\r
-% (this package loads the ae package in case it has not been loaded)\r
-% and with or without the french(le) package.\r
-%\r
-% In order to get the guillemets, it is necessary to either type\r
-% \guillemotleft and \guillemotright, or to use an 8 bit encoding\r
-% (such as ISO-Latin1) which selects these two commands, \r
-% or, if you use the french package (but not the frenchle package), \r
-% to type << or >>.\r
-%\r
-% By default, you get the Polish CMR guillemets; if this package is loaded\r
-% with the `cm' option, you get the LASY guillemets; with `ec,' you\r
-% get the EC guillemets, and with `cyr,' you get the cyrillic guillemets.\r
-%\r
-% In verbatim mode, you always get the EC/TT guillemets.\r
-%\r
-% The default option is interesting in conjunction with PDF,\r
-% because there is a Type 1 version of the Polish CMR fonts\r
-% and these guillemets are very close in shape to the EC guillemets.\r
-% There are no free Type 1 versions of the EC fonts.\r
-%\r
-% Support for Polish CMR guillemets was kindly provided by \r
-% Rolf Niepraschk <niepraschk@ptb.de> in version 0.99 (2000/05/22).\r
-% Bernd Raichle provided extensive simplifications to the code\r
-% for version 1.00.\r
-%\r
-% This package is released under the LPPL.\r
-%\r
-% Changes:\r
-% Date version\r
-% 2001/04/12 1.01 the frenchle and french package are now distinguished.\r
-%\r
-\def\fileversion{1.01}\r
-\def\filedate{2001/04/12}\r
-\NeedsTeXFormat{LaTeX2e}\r
-%\ProvidesPackage{aeguill}[2001/04/12 1.01 % % GM\r
-%AE fonts with french guillemets (D. Roegel)] % GM - keeping the log file clean(er)\r
-%\RequirePackage{ae} % GM May 2007 - already embedded here\r
-\r
-\newcommand{\@ae@switch}[4]{#4}\r
-\DeclareOption{ec}{\renewcommand\@ae@switch[4]{#1}}\r
-\DeclareOption{cm}{\renewcommand\@ae@switch[4]{#2}}\r
-\DeclareOption{cyr}{\renewcommand\@ae@switch[4]{#3}}\r
-\DeclareOption{pl}{\renewcommand\@ae@switch[4]{#4}}\r
-\ExecuteOptions{pl}\r
-\ProcessOptions\r
-\r
-%\r
-% Load necessary packages\r
-%\r
-\@ae@switch{% ec\r
- % do nothing\r
-}{% cm\r
- \RequirePackage{latexsym}% GM - May 2007 - already 'mentioned as required' up above\r
-}{% cyr\r
- \RequirePackage[OT2,T1]{fontenc}%\r
-}{% pl\r
- \RequirePackage[OT4,T1]{fontenc}%\r
-}\r
-\r
-% The following command will be compared to \frenchname,\r
-% as defined in french.sty and frenchle.sty.\r
-\def\aeguillfrenchdefault{french}%\r
-\r
-\let\guill@verbatim@font\verbatim@font\r
-\def\verbatim@font{\guill@verbatim@font\ecguills{cmtt}%\r
- \let\guillemotleft\@oguills\let\guillemotright\@fguills}\r
-\r
-\begingroup \catcode`\<=13 \catcode`\>=13\r
-\def\x{\endgroup\r
- \def\ae@lfguill{<<}%\r
- \def\ae@rfguill{>>}%\r
-}\x\r
-\r
-\newcommand{\ecguills}[1]{%\r
- \def\selectguillfont{\fontencoding{T1}\fontfamily{#1}\selectfont}%\r
- \def\@oguills{{\selectguillfont\symbol{19}}}%\r
- \def\@fguills{{\selectguillfont\symbol{20}}}%\r
- } \r
-\r
-\newcommand{\aeguills}{%\r
- \ae@guills\r
- % We redefine \guillemotleft and \guillemotright\r
- % in order to catch them when they are used \r
- % with \DeclareInputText (in latin1.def for instance)\r
- % We use \auxWARNINGi as a safe indicator that french.sty is used.\r
- \gdef\guillemotleft{\ifx\auxWARNINGi\undefined\r
- \@oguills % neither french.sty nor frenchle.sty\r
- \else\r
- \ifx\aeguillfrenchdefault\frenchname\r
- \ae@lfguill % french.sty\r
- \else\r
- \@oguills % frenchle.sty\r
- \fi\r
- \fi}%\r
- \gdef\guillemotright{\ifx\auxWARNINGi\undefined\r
- \@fguills % neither french.sty nor frenchle.sty\r
- \else\r
- \ifx\aeguillfrenchdefault\frenchname\r
- \ae@rfguill % french.sty\r
- \else\r
- \@fguills % frenchle.sty\r
- \fi\r
- \fi}%\r
- }\r
-\r
-%\r
-% Depending on the class option\r
-% define the internal command \ae@guills\r
-\@ae@switch{% ec\r
- \newcommand{\ae@guills}{%\r
- \ecguills{cmr}}%\r
-}{% cm\r
- \newcommand{\ae@guills}{%\r
- \def\selectguillfont{\fontencoding{U}\fontfamily{lasy}%\r
- \fontseries{m}\fontshape{n}\selectfont}%\r
- \def\@oguills{\leavevmode\nobreak\r
- \hbox{\selectguillfont (\kern-.20em(\kern.20em}\nobreak}%\r
- \def\@fguills{\leavevmode\nobreak\r
- \hbox{\selectguillfont \kern.20em)\kern-.2em)}%\r
- \ifdim\fontdimen\@ne\font>\z@\/\fi}}%\r
-}{% cyr\r
- \newcommand{\ae@guills}{%\r
- \def\selectguillfont{\fontencoding{OT2}\fontfamily{wncyr}\selectfont}%\r
- \def\@oguills{{\selectguillfont\symbol{60}}}%\r
- \def\@fguills{{\selectguillfont\symbol{62}}}}\r
-}{% pl\r
- \newcommand{\ae@guills}{%\r
- \def\selectguillfont{\fontencoding{OT4}\fontfamily{cmr}\selectfont}%\r
- \def\@oguills{{\selectguillfont\symbol{174}}}%\r
- \def\@fguills{{\selectguillfont\symbol{175}}}}\r
-}\r
-\r
-\r
-\AtBeginDocument{%\r
- \ifx\GOfrench\undefined\r
- \aeguills\r
- \else\r
- \let\aeguill@GOfrench\GOfrench\r
- \gdef\GOfrench{\aeguill@GOfrench \aeguills}%\r
- \fi\r
- }\r
-\r
-\endinput\r
-%\r
-\r
+++ /dev/null
-\begin{figure}
-
-
-%\paragraph{Default settings}
-%\begin{grammar}
-
-%<statement> ::= <ident> `=' <expr>
-%\alt `for' <ident> `=' <expr> `to' <expr> `do' <statement>
-%\alt `{' <stat-list> `}'
-%\alt <empty>
-
-%<stat-list> ::= <statement> `;' <stat-list> | <statement>
-
-%\end{grammar}
-
-\caption{\label{fig:algorithm}\TOOL algorithm}
-\end{figure}
+++ /dev/null
-\mysection{Specification Language Design}\label{sec:specification}
-
-We begin by 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
-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 a 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 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 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
-Lines~\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 states 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
-a 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
-(Lines~\ref{line:rcuSpecReadInterfaceID} and~\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 properties 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.
-
-\squishlist
-\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.
-\squishend
-
-\mypara{\bf Ordering Points 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:
-\squishcount
-\item {\code{Potential\_Ordering\_Point} annotation:} The labeling of ordering
-points that identifies the location of a potential ordering point.
-\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.
-\countend
-
-These two constructs together identify ordering points. For
-example, assume that $A$ is an atomic operation that is potentially an
-ordering point under some specific
-condition. The developer would then write a
-\code{Potential\_Ordering\_Point} annotation with a condition
-\code{ConditionA} and a 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 where 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 rather than 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 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{\_version} 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 internal 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 developers 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. With this notion, 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}, both the \code{update} and \code{read} methods
-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{\small{method1(HB\_condition1)}}
-\code{\small{->}}
-\code{\small{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.
+++ /dev/null
-personal_ws-1.1 en 98
-runtime
-API
-dequeuing
-opCheck
-overviewing
-atomics
-PSO
-thrd
-IRIW
-optimizations
-atomicity
-potentialOP
-interleavings
-updaters
-Paraglider
-hb
-structureSpec
-lookups
-Lev
-enqueue
-resizing
-linearizability
-lrrr
-Amit
-cnt
-MCS
-InitVar
-bool
-multi
-spinlock
-trylock
-Mellor
-decrement
-Valeadis
-cst
-happensBefore
-SideEffect
-putAll
-dequeues
-DeclareStruct
-MPMC
-deque
-DefineFunc
-methodSpec
-STL
-lockfree
-opLabelCheck
-rf
-structureDefine
-SPSC
-sb
-sc
-hashtables
-Cppmem
-prev
-dequeue
-reorderings
-VYRD
-RW
-init
-TSO
-ConditionA
-Crummey
-sw
-opClear
-ccccc
-Valeiadis
-Relacy
-Concurrit
-postconditions
-iteratively
-NDetermin
-LabelA
-resize
-succ
-TVLA
-acq
-nondeterministic
-intra
-linearizable
-PreCondition
-DeclareVar
-hashtable
-boolean
-postcondition
-PostCondition
-CheckFence
-enqueues
-structs
-scalability
-struct
-opo
-newNode
-linearization
-CAS
-RCU
-Colvin
-dependences
+++ /dev/null
-\section{Technical}\label{sec:technical}
projects / cdsspec-compiler.git / commitdiff