This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via cbfb77bdcaba85ab2565bc373c83040eb7cbe6bb (commit) from 329d93c45a5dcdd5f80cfba198217e6178aaee78 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit cbfb77bdcaba85ab2565bc373c83040eb7cbe6bb Author: Phil Carns <[email protected]> Date: Thu Mar 15 22:12:16 2012 -0500 Gail edits: intro ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/intro.tex | 76 +++++++++++++++++++++--------------------- 1 files changed, 38 insertions(+), 38 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/intro.tex b/papers/2011/aesop/intro.tex index 9929ec8..ffda69a 100644 --- a/papers/2011/aesop/intro.tex +++ b/papers/2011/aesop/intro.tex @@ -2,25 +2,25 @@ \label{sec:intro} -HPC and distributed systems rely on a diverse collection of system +High-performance computing and distributed systems rely on a diverse collection of system software to provide shared services for applications. Examples include file storage, scheduling, security, checkpointing, web services, membership management, and fault detection. Today's systems demand that these services scale to hundreds of thousands of concurrent clients, with millions of clients expected in the near future. Developing system -software for this environment is a complex task due to a number of competing +software for this environment is a complex task because of a number of competing software engineering requirements: \begin{itemize} -\item scalable orchestration of concurrent client activity, -\item maintainable code for complex distributed algorithms, -\item portability across diverse architectures, -\item management of concurrent operations across multiple hardware devices, -\item and maximum performance on multiple platforms. +\item Scalable orchestration of concurrent client activity +\item Maintainable code for complex distributed algorithms +\item Portability across diverse architectures +\item Management of concurrent operations across multiple hardware devices +\item Maximum performance on multiple platforms \end{itemize} -Further complicating matters is the fact that system software services must -not only interact with multiple hardware devices concurrently, but do so using +Further complicating matters is the fact that system software services +not only must interact with multiple hardware devices concurrently but must do so using a wide assortment of interfaces and progress models. Popular network transports, disks, and local databases may present a simple set of blocking functions, fully asynchronous callbacks, or any one of a number of API models @@ -30,22 +30,22 @@ capable of leveraging each component in an optimal manner. The two most common models for managing asynchronous activity are multithreading and event-driven architectures. Examples of both can be found -in a variety of large scale production services. The Apache web server -advocates a multithreaded mode of operation for high performance +in various large-scale production services. The Apache web server +advocates a multithreaded mode of operation for high-performance deployments~\cite{apache-threads}. In contrast, the memcached object caching service uses an event-driven model with threads used to drive concurrent event loops~\cite{memcached-threads}. -Multithreading is popular for several reasons. First and foremost, this model -is widely used and therefore well understood in the development community. It +The multithreading model +is widely used and well understood in the development community. It produces a natural control flow in algorithm implementations because each thread executes sequentially and issues simple blocking device operations. Thread scheduling and stack management are handled by the operating system. -Threads also provide a clear model to express concurrency. There are a number -of challenges to building a multithreaded service, however. The first is +Threads also provide a clear model to express concurrency. +Building a multithreaded service raises a number of challenges, however. The first is that it is not always intuitive how to best provision thread resources; for network services, threads can be assigned per client, per request, or per -underlying device operation, and they may be created on demand or allocated +underlying device operation and they may be created on demand or allocated from an existing pool. Each technique or combination of techniques presents tradeoffs in scalability, performance, and readability. Yet it is difficult to transition between techniques during the development process. The second challenge @@ -56,36 +56,36 @@ storage device will be distinct from the optimal number of threads per processor core. This disconnect can cause a seemingly simple thread model to evolve into a more complex -framework when taking local resource scheduling constraints into account. +framework when taking local resource-scheduling constraints into account. Event-driven models can be used to address some of the common challenges in -thread efficiency. Event-driven models strive to unify the management of +thread efficiency. Such models strive to unify the management of asynchronous activities, so that the completion of any storage or network event triggers execution of the next servicing step through a centralized event handler. This architecture provides greater control over asynchronous activity and avoids the use of operating system threads to express logical concurrency. Any number of client requests can be tracked and serviced without -explicitly allocating a thread to each request. There are drawbacks to this -model as well, however. Event-driven architectures break the logical control +explicitly allocating a thread to each request. This +model has drawbacks as well, however. Event-driven architectures break the logical control flow of software algorithms into disjoint segments at each point where the algorithm interacts with an asynchronous device or operating system service. In effect, it turns the single linear control flow for an algorithm into a state machine with several independent states. Because these states are invoked from a centralized event handler, their interfaces must be consistent and generalized, making it difficult to verify design constraints. -Per-request state has to be managed -manually by the programmer, often referred to as {\em stack +State transfer across event handlers has to be managed +manually by the programmer, a process often referred to as {\em stack ripping}~\cite{krohn2007ecm}. Pure event-driven models also do not directly -address the requirement of multi-core architectures or high performance -peripherals that require multiple threads to achieve maximize throughput. +address the requirement of multicore architectures or high-performance +peripherals that require multiple threads to maximize throughput. Event-driven servers therefore tend to evolve during the development process to take on characteristics of both event-driven and multithreaded services in order to compensate for these issues. -In general, there is no clear-cut metric that can be used to identify the best +In general, no clear-cut metric can be used to identify the best concurrent programming model for a given system software project, yet this -decision affects every aspect of the design from algorithm implementation to -device management. In order to help address this problem, we propose a new +decision affects every aspect of the design, from algorithm implementation to +device management. To help address this problem, we propose a new programming language and programming model, \aesop, that targets the software engineering challenges associated with developing distributed system software. Its goal is to improve programmer productivity by presenting a convenient @@ -96,7 +96,7 @@ system or device. \aesop is a superset of the C language. It describes blocks of code that can be executed asynchronously or concurrently, without dictating whether those -blocks must be implemented with threads or not, and without dictating the +blocks must be implemented with threads, and without dictating the asynchronous progress model to be used by any underlying devices. Because the core algorithm description is decoupled from these architecture-specific details, the run-time system can be tuned to match different system @@ -106,21 +106,21 @@ architectures, the \aesop extensions do not suffer from an inversion of control, preserving readable control flow regardless of how many steps or concurrent devices are utilized in a given algorithm. \aesop also offers functionality that is not available in a traditional multithreaded or -event-driven framework, for example the ability to cleanly cancel outstanding +event-driven framework -- for example the ability to cleanly cancel outstanding operations. \subsection{Summary of contributions} -The contributions of this paper can be summarized as: +The contributions of this paper can be summarized as follows: \begin{itemize} -\item A description of a proposed programming model and language, known -as \aesop, for use in the development of distributed system software -\item The definition of new language constructs to aid managing highly +\item Description of a new programming model and language, \aesop, +for use in the development of distributed system software +\item Definition of new language constructs to help manage highly concurrent execution -\item An case study comparing \aesop to five popular multithreaded +\item Case study comparing \aesop to five popular multithreaded and event-driven architectures, using a simple distributed service as an example -\item A quantitative analysis of the code complexity of the architectures +\item Quantitative analysis of the code complexity of the architectures used in the case study \end{itemize} @@ -129,9 +129,9 @@ Sections~\ref{section:context} and~\ref{section:related} describe the challenges of distributed system software development and related work in addressing those challenges. Sections~\ref{section:model} and~\ref{section:implementation} present the \aesop programming model and -our implementation thereof. Section~\ref{section:evaluation} describes a simple -distributed service and uses it as a case study to contrast \aesop -against other models in terms of performance, memory efficiency, and +our implementation. Section~\ref{section:evaluation} describes a simple +distributed service and uses it as a case study to compare \aesop +with other models in terms of performance, memory efficiency, and productivity. Section~\ref{section:conclusion} summarizes our findings and proposes avenues of future work. hooks/post-receive -- Triton-private Repository