March 2012 - Triton-commits - mailman3.cels.anl.gov

Triton-private Repository branch, master, updated. 45933bc2e3817459b37c6fc12fe41e95eb9f3e63
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 45933bc2e3817459b37c6fc12fe41e95eb9f3e63 (commit) from 9931a6b61d4c8f355ca6487adda0f706ac470923 (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 45933bc2e3817459b37c6fc12fe41e95eb9f3e63 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 22:27:57 2012 -0500 bunch of negative vspace hacks ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/context.tex | 2 ++ papers/2011/aesop/evaluation.tex | 3 +++ papers/2011/aesop/implementation.tex | 1 + papers/2011/aesop/model.tex | 1 + 4 files changed, 7 insertions(+), 0 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/context.tex b/papers/2011/aesop/context.tex index 04a55be..6e3cd87 100644 --- a/papers/2011/aesop/context.tex +++ b/papers/2011/aesop/context.tex @@ -63,6 +63,7 @@ %$^\ast$In practice, I/O is typically aggregated through a limited %number \\ of clients \label{tab:scale} +\vspace{-.3in} \end{table} %% I spent a lot of time looking for the OST count on the K-computer @@ -105,6 +106,7 @@ an error is returned to the client. \caption{Concurrency in file system server. \label{fig:sm} } + \vspace{-.2in} \end{figure} diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index deefd3f..a94e0ae 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -109,6 +109,7 @@ follows. \caption{Run-time performance for each test case.\\ \footnotesize (X-axis is the number of client instances, each graph has a distinct Y-axis.)} +\vspace{-.2in} \end{figure*} \paragraph*{\aesop} @@ -248,6 +249,7 @@ write test is shown. \centering \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-lat.pdf} \caption{Write latency (1,024 clients).\label{fig:writelat}} +\vspace{-.15in} \end{figure} \subsection{Memory Efficiency} @@ -282,6 +284,7 @@ shown. \centering \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-mem.pdf} \caption{Write memory usage.\label{fig:writemem}} +\vspace{-.2in} \end{figure} \subsection{Productivity} diff --git a/papers/2011/aesop/implementation.tex b/papers/2011/aesop/implementation.tex index afce9d1..970352f 100644 --- a/papers/2011/aesop/implementation.tex +++ b/papers/2011/aesop/implementation.tex @@ -14,6 +14,7 @@ functions; all other code is passed through unmodified. \centering \includegraphics[keepaspectratio,width=0.48\textwidth]{stack.pdf} \caption{Model of Aesop usage.\label{fig:model}} + \vspace{-.2in} \end{figure} Figure~\ref{fig:model} shows how a blocking function, \code{service_function}, diff --git a/papers/2011/aesop/model.tex b/papers/2011/aesop/model.tex index b441b86..4c47b1f 100644 --- a/papers/2011/aesop/model.tex +++ b/papers/2011/aesop/model.tex @@ -169,6 +169,7 @@ __blocking void write (...) { } } \end{lstlisting} +\vspace{-.4in} \end{figure} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 9931a6b61d4c8f355ca6487adda0f706ac470923
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 9931a6b61d4c8f355ca6487adda0f706ac470923 (commit) from cbfb77bdcaba85ab2565bc373c83040eb7cbe6bb (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 9931a6b61d4c8f355ca6487adda0f706ac470923 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 22:16:19 2012 -0500 Gail edits: abstract ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index fd457a1..18c3ab7 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -106,12 +106,12 @@ Argonne, IL 60439\\ \maketitle \begin{abstract} -High Performance Computing (HPC) and distributed systems rely on a diverse +High-performance computing (HPC) and distributed systems rely on a diverse collection of system software to provide application services, including file systems, schedulers, web services, and fault detectors. Such system software services must manage highly concurrent requests, interact with a wide range of -resources, and scale well in order to be successful. Unfortunately, there is -no single programming model for distributed system software that offers +resources, and scale well in order to be successful. Unfortunately, +no single programming model for distributed system software currently offers optimal performance and productivity for all these tasks. In addition, many concurrent server architectures introduce software complexity that interferes with algorithm development and hinders software maintenance and portability. @@ -123,20 +123,20 @@ computational resources. In this work we present \aesop, a new programming language and programming model designed to implement distributed system software with high development -productivity and run time efficiency. \aesop is a superset of the C language -that describes blocks of code to be executed concurrently without dictating if -that concurrency will be provided by a threading, event, or other model. This -decoupling of algorithm description and run time implementation enables system +productivity and run-time efficiency. \aesop is a superset of the C language +that describes blocks of code to be executed concurrently without dictating +whether that concurrency will be provided by a threading, event, or other model. This +decoupling of algorithm description and run-time implementation enables system software to adjust to different architectures, device APIs, and workloads without any change to the core algorithm implementation. \aesop also provides -a set of language constructs that provide more expressive control over +a set of language constructs that enable more expressive control over concurrent execution than is typically found in multithreaded or event-driven programming models. We evaluate \aesop by implementing a simple file server and comparing its -performance, memory efficiency, and developer productivity to several +performance, memory efficiency, and developer productivity with several thread-based and event-based implementations. \aesop is shown to provide -competitive (and in some cases superior) performance to traditional +competitive -- and, in some cases, superior -- performance to traditional distributed system software development models while at the same time reducing code complexity and enhancing developer productivity. \end{abstract} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. cbfb77bdcaba85ab2565bc373c83040eb7cbe6bb
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 <carns(a)mcs.anl.gov> 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

1 0

Triton-private Repository branch, master, updated. 329d93c45a5dcdd5f80cfba198217e6178aaee78
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 329d93c45a5dcdd5f80cfba198217e6178aaee78 (commit) from 36d4a51d93b2a825a874eafe48000c0654b74e6c (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 329d93c45a5dcdd5f80cfba198217e6178aaee78 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 21:53:57 2012 -0500 Gail edits: context section ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/context.tex | 55 +++++++++++++++++++++-------------------- 1 files changed, 28 insertions(+), 27 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/context.tex b/papers/2011/aesop/context.tex index ff047e1..04a55be 100644 --- a/papers/2011/aesop/context.tex +++ b/papers/2011/aesop/context.tex @@ -73,7 +73,7 @@ Large-scale distributed and parallel systems rely on distributed system software to provide scalable access to persistent services. For example, a parallel file system aggregates distributed storage resources provided by multiple servers into a unified name space. Each individual service program -expects many concurrent accesses from multiple clients, and in turn launches +expects many concurrent accesses from multiple clients, and, in turn, launches multiple overlapping operations such as network transmissions or disk drive operations. Table~\ref{tab:scale} details the configuration of some existing and predicted deployments of parallel file systems. A large parallel file @@ -84,15 +84,15 @@ operations. %% \todo{This might be a good place for a mini plot or table.} -\subsection{Motivation: Concurrency in file system services} +\subsection{Motivation: Concurrency in File System Services} Consider the file server depicted in Figure~\ref{fig:sm}. The operation starts when the client issues a request to the server, triggering the top receive. The server then simultaneously issues four concurrent operations: a -send to peer server to forward data to a replica, a receive to accept the +send to a peer server to forward data to a replica, a receive to accept the response from the replica server, a timer call to ensure the request completes -within a reasonable time, and a sequence of metadata operations. Finally, -when all operations complete before the timer expires, the timer is cancelled +within a reasonable time, and a sequence of metadata operations. +If all operations complete before the timer expires, the timer is cancelled, and the result is posted to the client. However, if the timeout is reached before the other tasks complete, all unfinished operations are cancelled and an error is returned to the client. @@ -108,14 +108,14 @@ an error is returned to the client. \end{figure} -This file system server algorithm example illustrates that concurrency -arises not only from simultaneous client access, but also from the +This example illustrates that concurrency +arises not only from simultaneous client access but also from the steps required to service each request. Ideally, -programming models should help to manage this concurrency, enhancing +programming models should help manage this concurrency, enhancing developer productivity. Note that this is a simplified example. -A production quality file system server additionally requires pipelining, -failure handling and retry functionality that, in practice, further -complicates its implementation. +A production-quality file system server additionally requires pipelining, +failure handling, and retry functionality, all of which further +complicate its implementation. %% ... todo: pick up train of thought here, expect concurrent access %% (both coordinated and uncoordinated) from application processes, means @@ -214,21 +214,21 @@ their interface models. For a device exporting a blocking interface, function calls do not return until the request described by the call is completed. Concurrency is typically achieved by calling multiple functions simultaneously from multiple threads. However, for scheduling and efficiency reasons -(described in section~\ref{sec:intro}), high performance storage and -networking APIs typically provide non-blocking interfaces to achieve I/O +(described in Section~\ref{sec:intro}), high-performance storage and +networking APIs typically provide nonblocking interfaces to achieve I/O concurrency. -Non-blocking interfaces follow an \emph{event-driven model}, where a request -for an \emph{I/O operation} is made to the device through a function call, +Nonblocking interfaces follow an \emph{event-driven model}, where a request +for an I/O operation is made to the device through a function call, which returns without waiting for completion (the function does not block). The program receives completion of the I/O operation (the event) through other notification paths, such as through a polling function or asynchronous -function callbacks. Non-blocking interfaces achieve concurrency by enabling +function callbacks. Nonblocking interfaces achieve concurrency by enabling the posting of multiple I/O operations without waiting for their completion. -%While a non-blocking interface +%While a nonblocking interface %allows the device to receive and optimize many requests, it hinders %expressiveness of the concurrent program. Event-driven software is %inherently difficult to write, understand and debug, primarily because @@ -247,21 +247,21 @@ the posting of multiple I/O operations without waiting for their completion. %% Infiband verbs API, IT-API (Interconnect Transport API), %% Myricom MX, -%\subsection*{Summary of non-blocking APIs} +%\subsection*{Summary of nonblocking APIs} -%File system services make heavy use of non-blocking APIs for both +%File system services make heavy use of nonblocking APIs for both %network and disk access. -Network sockets offers multiple potential APIs, including non-blocking APIs +Network sockets offers multiple potential APIs, including nonblocking APIs and polling. Use of InfiniBand~\cite{IBVerbs,balaji2006azc} through the {\tt libibverbs} API offers a post/poll interface to send/receive queues~\cite{ITAPI,RDMA_2010}. Myrinet~\cite{Myrinet_1995} provides a rich API through the MX interface~\cite{MX_Guide_2006} that offers asynchronous send/receive operations with test, probe, and callback registration. However, -straightforward use of the callbacks block the network progress thread. The +straightforward use of the callbacks blocks the network progress thread. The IBM Deep Computing Messaging Framework (DCMF)~\cite{BGP_RMA_2008} primarily -offers non-blocking calls for send/receive and one-sided put/get -communication. MPI-2~\cite{gropp1999ump,snir1995mcr} offers non-blocking +offers nonblocking calls for send/receive and one-sided put/get +communication. MPI-2~\cite{gropp1999ump,snir1995mcr} offers nonblocking messaging calls for point-to-point communication. Unix systems have traditionally offered the select/poll paradigm, in which @@ -280,17 +280,18 @@ of file descriptors. %% Addressed. -Justin -Disk operations also have a range of non-blocking access methods. POSIX +Disk operations also have a range of nonblocking access methods. POSIX AIO~\cite{POSIX_AIO_2006} offers multiple models for controlling asynchronous I/O, including the ability to supply a signal or callback function for completion notification. Additionally, the user may manually place disk operations in separate threads to enhance concurrency. -Databases are commonly used for file system metadata and the efficient use of -them is critical. Berkeley~DB~\cite{BDB_1999} does not provide a non-blocking +Databases are commonly used for file system metadata, and the efficient use of +them is critical. Berkeley~DB~\cite{BDB_1999} does not provide a nonblocking API, but wrapper libraries have been used to achieve this. Postgres offers an asynchronous interface~\cite{postgresAsync} in its C API that allows database -operations to be posted asynchronously; a separate library function tests if a +operations to be posted asynchronously; a separate library function tests +whether a complete operation may be accessed. % Discuss continued use of C/C++ in systems software: hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 36d4a51d93b2a825a874eafe48000c0654b74e6c
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 36d4a51d93b2a825a874eafe48000c0654b74e6c (commit) from e5701b53c10a1800316b6d619f372b218550b0ca (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 36d4a51d93b2a825a874eafe48000c0654b74e6c Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 21:43:31 2012 -0500 Gail edits: related work ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/related.tex | 45 +++++++++++++++++++++-------------------- 1 files changed, 23 insertions(+), 22 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/related.tex b/papers/2011/aesop/related.tex index b7fec39..c33afaf 100644 --- a/papers/2011/aesop/related.tex +++ b/papers/2011/aesop/related.tex @@ -2,9 +2,9 @@ \section{Related Work} \label{section:related} -The \aesop language described in this work builds upon lessons learned from +The \aesop language described in this work builds on lessons learned from the event-driven state machine model used in the PVFS file -system~\cite{pvfs-web}. In PVFS State Machines (SM), every client and server +system~\cite{pvfs-web}. In PVFS state machines (SMs), every client and server operation is expressed as a state machine using a language that is based on C with extensions to describe service states and the transitions that link them. A state is simply a C function. Each state function can optionally end by @@ -12,38 +12,38 @@ submitting an asynchronous network, disk, timer, or pipeline operation through an API that provides unified notification of completion events for each device. When one of these operations completes, a state machine engine maps the operation back to the appropriate state machine and executes the next -state function depending upon the outcome of the asynchronous operation. -Multiple state machines instances can be active simultaneously, allowing PVFS +state function, depending on the outcome of the asynchronous operation. +Multiple state machine instances can be active simultaneously, allowing PVFS to track the state of an arbitrary number of concurrent requests and make progress on them without the overhead of explicit threading. -This PVFS state machine model is essentially a formal framework for +The PVFS state machine model is essentially a formal framework for event-driven programming. This approach has proved successful in achieving high performance in large-scale production HPC environments~\cite{pvfs-bgp-sc09}, but it shares many of the same developer productivity challenges found in other event-driven models. First, all algorithms must be split into functions on boundaries according to the location of asynchronous operations, rather than according to logical -functionality. Secondly, the state machine engine uses a fixed function +functionality. Second, the state machine engine uses a fixed function prototype for each state machine function, meaning that arguments are passed between state functions via an opaque struct that is shared across the entire -state machine. This makes automatic depencency checking between states +state machine. This makes automatic dependency checking between states impossible (e.g., did the previous state function set all of the struct fields needed by the current state function?) and leads to a new class of bugs that do not typically appear in traditional C code. Additionally, PVFS SMs perform all non-asynchronous computation on a single core, which is an undesirable -model given the advent of many-core servers. Finally, PVFS SM code does not +model given the advent of many-core servers. Moreover, PVFS SM code does not resemble traditional C code, making it difficult to reason about many development challenges. -These drawbacks introduce a learning curve for researchers and a additional +These drawbacks introduce a learning curve for researchers and an additional maintenance workload for maintainers. In this work, we seek to learn from the lessons of PVFS SM development and present a programming model that provides at least as much technical functionality but also allows file system developers to write algorithms using a more traditional code organization. A number of programming languages and programming models have been developed -to express application-level concurrency and efficiently leverage multi-core +to express application-level concurrency and efficiently leverage multicore architectures. Examples include OpenMP~\cite{Chandra:2001:PPO:355074}, X10~\cite{Charles:2005:XOA:1094811.1094852}, Unified Parallel C~\cite{upc-intro}, Chapel~\cite{Chamberlain:2007:PPC:1286120.1286123}, @@ -53,8 +53,8 @@ parallel, including constructs for synchronization and sharing variables. While many of these constructs share principles with \aesop, they were developed with the goal of coordinating computation on multiple cores at the application level, rather than coordinating asynchronous activity on multiple -I/O devices at the system software level. As a result these languages -optimize for maximum use of available CPU resources, while \aesop instead +I/O devices at the system software level. As a result, these languages +optimize for maximum use of available CPU resources, whereas \aesop optimizes for maximum use of underlying devices that may or may not require significant CPU activity. The level of \aesop concurrency is not correlated with the number of CPU cores available, though \aesop can utilize @@ -63,10 +63,10 @@ multiple cores (if available) to improve latency and concurrency. % this is repeated from above \aesop has clear similarities to OpenMP, the C/Fortran language extensions for expressing thread parallelism. In particular \aesop supports decoupling -sequential control flow (i.e. parallel for), waiting for their completion -(barrier) and the annotation of variables to indicate if they are to be shared -or private with respect to concurrent execution flows. As all these concepts -are present in OpenMP as well, it's easy to see how \aesop might be used to +sequential control flow (i.e., parallel for), waiting for their completion +(barrier) and the annotation of variables to indicate whether they are to be shared +or private with respect to concurrent execution flows. Since all these concepts +are present in OpenMP as well, it is easy to see how \aesop might be used to write multithreaded applications. However, this is not the primary focus of \aesop. \aesop does not create or require threads. While OpenMP mainly provides a portable thread abstraction, it does not offer any support for @@ -83,17 +83,18 @@ then it may instantiate a larger number of threads. The primary advantages of GCD are that it simplifies multithreaded programming and automatically adjusts concurrency according to the workload and the system architecture. Unlike \aesop, however, GCD always uses threads to achieve concurrency and provides -no general framework for integration with device API's that provide more -scalable asynchronous interfaces. GCD does not support cancellation of tasks. +no general framework for integration with device APIs that provide more +scalable asynchronous interfaces. Moreover, GCD does not support cancellation of tasks. -In addition to programming models and languages, a number of support libraries -have also been developed to aid in portably managing a large number of +In addition to programming models and languages, several support libraries +have been developed to aid in portably managing a large number of asynchronous events. Examples include libevent~\cite{libevent-web} and -libev~\cite{libev-web}. Such libraries provide an efficient unified API for +libev~\cite{libev-web}. Such libraries provide a unified API for managing multiple kinds of events, particularly on sockets or file descriptors. While such libraries solve an important technical problem related to service efficiency, they do not address the programmability aspect -of event-driven concurrent programming. It is up to the developer to fit his +of event-driven concurrent programming. The developer is left the task of +fitting their algorithm logic to the basic event-driven model. % *Research* work on expressiveness of concurrency: hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. e5701b53c10a1800316b6d619f372b218550b0ca
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 e5701b53c10a1800316b6d619f372b218550b0ca (commit) from 314fbd23937dc125b797259898b8488d042a28d1 (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 e5701b53c10a1800316b6d619f372b218550b0ca Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 21:38:09 2012 -0500 missing edit to prog model section ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/model.tex | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/model.tex b/papers/2011/aesop/model.tex index 6abbf5c..b441b86 100644 --- a/papers/2011/aesop/model.tex +++ b/papers/2011/aesop/model.tex @@ -138,7 +138,7 @@ multiple threads will be used to execute those branches concurrently. \begin{figure} \center - \begin{lstlisting}[caption={Aesop code example}, + \begin{lstlisting}[caption={Aesop code example.}, label=lst:parallelfor] __blocking void doReplicaWrite (...) { pwait { hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 314fbd23937dc125b797259898b8488d042a28d1
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 314fbd23937dc125b797259898b8488d042a28d1 (commit) via 8000faa2c45b31c300a600561cc59be86d738e39 (commit) from 31ecc4a14bdeeed9cd52a1c56974a513b5dbec64 (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 314fbd23937dc125b797259898b8488d042a28d1 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 21:35:03 2012 -0500 captions don't like \aesop I guess? commit 8000faa2c45b31c300a600561cc59be86d738e39 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 21:34:52 2012 -0500 Gail edits: programming model section ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/implementation.tex | 4 +- papers/2011/aesop/model.tex | 104 +++++++++++++++++----------------- 2 files changed, 53 insertions(+), 55 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/implementation.tex b/papers/2011/aesop/implementation.tex index 933abcb..afce9d1 100644 --- a/papers/2011/aesop/implementation.tex +++ b/papers/2011/aesop/implementation.tex @@ -13,9 +13,7 @@ functions; all other code is passed through unmodified. %\vskip -0.25in \centering \includegraphics[keepaspectratio,width=0.48\textwidth]{stack.pdf} - \caption{Model of \aesop usage. - \label{fig:model} - } + \caption{Model of Aesop usage.\label{fig:model}} \end{figure} Figure~\ref{fig:model} shows how a blocking function, \code{service_function}, diff --git a/papers/2011/aesop/model.tex b/papers/2011/aesop/model.tex index ab61b63..6abbf5c 100644 --- a/papers/2011/aesop/model.tex +++ b/papers/2011/aesop/model.tex @@ -5,34 +5,35 @@ program model. \subsection{Parallel Branches} -Concurrency is expressed in \aesop through the use of {\em parallel branches} +Concurrency is expressed in \aesop through the use of {\em parallel branches}, or {\em pbranches}. A parallel branch groups a list of statements and supports branch-scoped variables, much like a regular function. Within a pbranch, statements are executed sequentially, as in a normal C program. -However, when multiple pbranches are active, the \aesop language only enforces -sequential execution within the scope of a single pbranch. Statements from +When multiple pbranches are active, however, the \aesop language enforces +sequential execution only within the scope of a single pbranch. Statements from other pbranches might interleave execution or might execute concurrently (using a thread for example). -It is possible to synchronize with pbranches using the \code{pwait} construct. +\aesop can synchronize pbranches by using the \code{pwait} construct. A pwait is similar to the barrier implicit in many OpenMP directives (such as parallel for), in that no statements following the pwait will execute unless -all of the pbranches it encloses have completed. +all the pbranches it encloses have completed. -By default, variables in \aesop are shared between pbranches. This is similar +By default, variables in \aesop are shared between pbranches. This +configuration is similar to OpenMP, where variables are shared between multiple threads unless indicated otherwise. Marking a variable as \code{pprivate} gives each pbranch -a private shadow copy, initialized using the shared instance when the branch -is created. Variables declared within a pbranch are -- adhering to the C -scoping rules -- necessarily private. +a private shadow copy, initialized by using the shared instance when the branch +is created. Variables declared within a pbranch are, adhering to the C +scoping rules, necessarily private. -It is possible for a pbranch to request the termination (or cancellation) of +A pbranch can request the termination (or cancellation) of all other pbranches within the same pwait by calling the \code{aesop_cancel_branches} function. This function returns as soon as the other pbranches have been marked for cancellation; it is asynchronous in that it does not wait for the other pbranches to exit. While pbranches are not forcibly terminated, a pbranch with an outstanding cancellation request -affects branch execution to ensure a race free delivery of the cancellation +affects branch execution to ensure a race-free delivery of the cancellation signal. If the pbranch is in a function call when the cancellation signal arrives, that function will be notified of the cancellation, enabling the function to take whatever steps necessary to cancel the operation and return a @@ -50,58 +51,58 @@ the needed code to do so. For example, if a device exposes an asynchronous API, \aesop will automatically call the corresponding \code{cancel} function when a pbranch waiting for the completion of an operation is cancelled. Many other libraries aimed at concurrent or asynchronous execution do not -support cancellation or only offer limited support. +support cancellation or offer only limited support. In Grand Central Dispatch, once a code block is dispatched to a queue, it can no longer be removed or cancelled. Likewise, OpenMP does not support cancelling helper threads in parallel for and other concurrency constructs. In both cases, the recommended practice is for the programmer to repeatedly check a cancellation flag. This becomes especially cumbersome if other -functions are called from within the concurrent code, as now those functions -have to have access to the cancellation variable as well. +functions are called from within the concurrent code, since now those functions +must have access to the cancellation variable as well. While the POSIX thread API supports a number of different cancellation modes, using them in production software is not trivial. In the \code{asynchronous} cancellation mode, depending on the system, thread execution might be halted -at any point, making it very hard for the programmer to properly track cleanup +at any point, making it hard for the programmer to properly track cleanup state. In the default \code{deferred} mode, cancellation is ignored by all but a small list of special functions (termed \code{cancellation points}). Many common C functions, such as \code{fread}, -may or may not -- depending on the system -- support cancellation. Most -don't support cancellation at all. This means that a portable program cannot +may or may not, depending on the system, support cancellation. Most +do not. Thus, a portable program cannot call any of these functions if timely cancellation is required. -\aesop also supports {\em lonely pbranches}, i.e.\ pbranches created outside -of a pwait. A lonely pbranch is similar to a POSIX detached thread in that +\aesop also supports {\em lonely pbranches}, that is, pbranches created outside +a pwait. A lonely pbranch is similar to a POSIX detached thread in that lonely pbranches cannot be cancelled or synchronized with. \subsection{Blocking Functions} \aesop extends the C programming language with a new function type: {\em -blocking} functions. The blocking qualifyier is part of the type. A pointer to +blocking} functions. The blocking qualifier is part of the type. A pointer to a regular C function is not compatible with a function pointer to a blocking function with the same function arguments. Blocking functions differ from regular C functions in that only blocking functions can contain pbranches. -In addition, blocking functions support {\em cancellation}. +In addition, blocking functions support cancellation. Functions can be made blocking by adding the \code{__blocking} -qualifier to the function declaration. However, blocking functions can only be -called (either directly or indirectly through a blocking function pointer) by -other blocking functions. This effectively requires the starting function of -an \aesop program to be blocking. \aesop libraries form an exception to this +qualifier to the function declaration. However, blocking functions can be +called (either directly or indirectly through a blocking function pointer) only by +other blocking functions. Thence, the starting function of +an \aesop program must be blocking. \aesop libraries form an exception to this rule. To simplify calling \aesop libraries from C -and other languages, it is possible to generate C function stubs for a -blocking \aesop function. These stubs can either be synchronous, in which case -the stub only returns once the blocking function completed, or asynchronous, +and other languages, one can generate C function stubs for a +blocking \aesop function. These stubs can be either synchronous, in which case +the stub returns only after the blocking function completed, or asynchronous, in which case the stub returns as soon as progress can no longer be made. -To handle completion in the latter case, a callback -- called when the -blocking function completes -- can be specified. +In order to handle completion in the latter case, a callback, called when the +blocking function completes, can be specified. % cancellation An active blocking function in a pbranch receiving a cancellation request will -be notified of the cancellation. The effect of this notification, and the way -the function reacts to this request, depends on the implementation of that +be notified of the cancellation. The effect of this notification and the way +the function reacts to this request depend on the implementation of that particular function. Likewise, any subsequent blocking call initiated in that pbranch will learn of the active cancellation request. While this is not enforced by the language, a proper blocking function should return as soon as @@ -109,10 +110,10 @@ possible when a branch is in a cancelled state. % when to use blocking functions -The intention is that functions that are not completely cpu-bound (i.e. cannot +The intention is that functions that are not completely cpu-bound (i.e., cannot efficiently fully consume a thread) are to be made blocking. The \aesop language provides a way for blocking functions to indicate they can no longer -make progress (for example because the function is waiting on an external +make progress (for example, because the function is waiting on an external event or device). When this happens, execution will continue in another branch. @@ -123,21 +124,21 @@ that, when one or more pbranches within the program are ready to execute, at least one of them will make progress. For example, in a pwait containing two branches, if one branch should stall on a blocking function (for example waiting for I/O), execution will proceed in the second pbranch provided that -pbranch is ready to do so. +pbranch is ready. % multiple threads In effect, the \aesop programming model provides for multiplexing multiple -pbranches onto a single thread or core, similar to application implemented +pbranches onto a single thread or core, similar to application-implemented user space threading with voluntary yielding. This does not preclude true -multi-threading; \aesop is fully thread-safe, and it is possible to have -multiple OS threads executing within a single aesop program. In fact, -we routinely use multiple threads to run aesop +multithreading; \aesop is fully thread-safe and +multiple OS threads can execute within a single \aesop program. In fact, +we routinely use multiple threads to run \aesop code. In that case, if more than one pbranch becomes ready for execution, multiple threads will be used to execute those branches concurrently. \begin{figure} \center - \begin{lstlisting}[caption={Aesop Code Example}, + \begin{lstlisting}[caption={Aesop code example}, label=lst:parallelfor] __blocking void doReplicaWrite (...) { pwait { @@ -173,10 +174,10 @@ __blocking void write (...) { \subsection{Example Aesop Code} \label{sec:example} -Listing~\ref{lst:parallelfor} shows a common aesop code pattern. -Network servers, having a finite set of resources, have to protect against -unbounded resource consumption by misbehaving or failing peers. This is -typically done by placing an upper limit on the time resources are dedicated +Listing~\ref{lst:parallelfor} shows a common \aesop code pattern. +Network servers, having a finite set of resources, must protect against +unbounded resource consumption by misbehaving or failing peers. +Typically, an upper limit is placed on the time resources are dedicated to a request, cancelling the request when the allocated time is exceeded. @@ -186,20 +187,19 @@ Since the pbranch statement does not wait for the completion of the branch, the next iteration of the \code{for} loop can start before the previous one completed. In \code{replicateWrite}, a common pattern for easily handling time-outs can be seen. Two pbranches are created, one to execute the work and -the other one to bound maximum time the other branch is allowed to execute. +the other to bound the maximum time the other branch is allowed to execute. When one of the branches completes, as a last task it cancels the other -branch. This means that if \code{doReplicateWrite} (line 15) completes first, +branch. Thus, if \code{doReplicateWrite} (line 15) completes first, the operation completed within the allocated time frame, and the timer (line 4) will be cancelled. However, if line 15 takes longer than \code{TIMEOUT} -milliseconds, the timer (line 11) will complete first causing the ongoing +to complete, the timer (line 11) will complete first, causing the ongoing \code{doReplicaWrite} operation to be cancelled. Note how \code{replicaWrite}, -in a straightforward an reusable manner, adds a time-out to the existing +in a straightforward and reusable manner, adds a time-out to the existing \code{doReplicaWrite} call. The short code fragment from listing~\ref{lst:parallelfor} effectively -implemented the pattern shown in figure~\ref{fig:sm}, in which a number of -concurrent write operations are started, each consisting of three tasks which -can be executed concurrently and each write operation is protected by a time -out. +implemented the pattern shown in Figure~\ref{fig:sm}, in which a number of +concurrent write operations are started; each consists of three tasks that +can be executed concurrently, and each write operation is protected by a timeout. hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 31ecc4a14bdeeed9cd52a1c56974a513b5dbec64
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 31ecc4a14bdeeed9cd52a1c56974a513b5dbec64 (commit) from 54ac7427b9e8e97fadac68d7bd1d0d909c03ca6f (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 31ecc4a14bdeeed9cd52a1c56974a513b5dbec64 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 20:58:17 2012 -0500 should have been in last commit ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/implementation.tex | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/implementation.tex b/papers/2011/aesop/implementation.tex index 9ed173f..933abcb 100644 --- a/papers/2011/aesop/implementation.tex +++ b/papers/2011/aesop/implementation.tex @@ -13,7 +13,7 @@ functions; all other code is passed through unmodified. %\vskip -0.25in \centering \includegraphics[keepaspectratio,width=0.48\textwidth]{stack.pdf} - \caption{Model of Aesop usage. + \caption{Model of \aesop usage. \label{fig:model} } \end{figure} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 54ac7427b9e8e97fadac68d7bd1d0d909c03ca6f
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 54ac7427b9e8e97fadac68d7bd1d0d909c03ca6f (commit) from 0d1347672166e05b7ec5f6338e7509d3122fc795 (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 54ac7427b9e8e97fadac68d7bd1d0d909c03ca6f Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 20:57:45 2012 -0500 Gail edits: implementation ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/implementation.tex | 50 +++++++++++++++++----------------- 1 files changed, 25 insertions(+), 25 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/implementation.tex b/papers/2011/aesop/implementation.tex index 53c3f78..9ed173f 100644 --- a/papers/2011/aesop/implementation.tex +++ b/papers/2011/aesop/implementation.tex @@ -1,12 +1,12 @@ \label{section:implementation} We implemented the \aesop language using a source-to-source translator. It -processes \aesop code, and rewrites \aesop specific functionality using -standard C constructs, emitting fully compliant C code. Because of this, -\aesop code can be deployed on any system that provides a suitable C compiler. -As \aesop implements an extension to the C language, all valid C programs are -also valid \aesop programs and all C features can be used within an \aesop -program. Currently, the translator only needs to rewrite \code{__blocking} +processes \aesop code and rewrites \aesop-specific functionality using +standard C constructs, emitting fully compliant C code. +\aesop code can therefore be deployed on any system that provides a suitable C compiler. +Since \aesop implements an extension to the C language, all valid C programs are +also valid \aesop programs, and all C features can be used within an \aesop +program. Currently, the translator needs to rewrite only \code{__blocking} functions; all other code is passed through unmodified. \begin{figure} @@ -18,26 +18,26 @@ functions; all other code is passed through unmodified. } \end{figure} -Figure~\ref{fig:model} shows how a blocking function \code{service_function} +Figure~\ref{fig:model} shows how a blocking function, \code{service_function}, is translated by the current version of the \aesop translator. As a first step, all blocking function calls within the function body are located. Based on the location of the blocking calls, the function is effectively split in a -set of code blocks (states), where each code block only contains non-blocking +set of code blocks (states), where each code block contains only nonblocking (traditional C) function calls. The blocking calls themselves are rewritten in an asynchronous form. For example, \code{network_operation} becomes \code{post_network_operation}. This post function becomes the last statement of the code block, where the first statement following the \code{network_operation} call becomes the first statement of the next block. As part of the \code{post_network_operation} call, \aesop provides a callback -argument which indicates where execution needs to continue once the operation +argument that indicates where execution needs to continue once the operation completes. As soon as the operation is posted, \code{service_function} returns, unwinding the stack. Depending on the state and structure of the program, the stack might unwind all the way down to the internal \aesop -function which initially called \code{aesop_main}, the \code{__blocking} -starting point of an \aesop program. When this happens, \aesop will try to +function that initially called \code{aesop_main}, the \code{__blocking} +starting point of an \aesop program. When this situation happens, \aesop will try to make progress on any pending operation, until one or more operations complete. -As part of the completion, the callback (passed to the post function, for -example \code{post_network_operation}) will be invoked, effectively resuming +As part of the completion, the callback argument (passed to the post function, for +example, \code{post_network_operation}) will be invoked, effectively resuming execution with the statement following the \code{__blocking} call. Our current translator does not actually split a blocking function into @@ -46,19 +46,19 @@ multiple independent functions. Instead, the function signature is modified generated at the beginning of the function. The jump table uses the \code{goto} instruction to jump to a specific label within the function. Labels are inserted at the beginning of each internal state (typically the -beginning of the function, and every statement following a blocking call). -These modifications make it possible to continue the function at the appropriate +beginning of the function and every statement following a blocking call). +These modifications enable the function to be continued at the appropriate location once its execution can be resumed. As an optimization, \aesop recognizes when an operation completes before the post function returns. When this happens, no stack -unwinding occurs and execution immediately continues with the next state +unwinding occurs, and execution immediately continues with the next state in the function. % variables, state management -Because variables local to the function scope are stored on the stack, and are -destroyed when returning from the function, \aesop\ -- as part of the -rewriting process -- moves all function scope variables (and function +Because variables local to the function scope are stored on the stack and are +destroyed when returning from the function, \aesop\, as part of the +rewriting process, moves all function scope variables (and function arguments) into a context structure on the heap, transparently rewriting variable references to account for this change. A pointer to this context is passed to the callback when the execution of the function resumes. @@ -67,20 +67,20 @@ passed to the callback when the execution of the function resumes. Within a given context, \aesop keeps track of pending operations. When a request is made to cancel concurrent branches, \aesop will call the correct cancellation function for each pending operation in the current context. To do -so, \aesop needs to know, for each blocking call, how to cancel operation. +so, \aesop needs to know, for each blocking call, how to cancel the operation. For blocking functions translated by \aesop (those marked by \code{__blocking}), \aesop internally provides the cancel methods. -However, for operations managed by an existing, external library (for example -AIO), this information needs to be provided to \aesop. This is done by +However, for operations managed by an existing, external library (for +example, AIO), this information needs to be provided to \aesop. This is done by creating a {\em resource}. \aesop resources enable implementing an \aesop blocking function using pure C. Resources are typically used to provide an \aesop binding on top of an existing C library. A resource exports an \aesop -API consisting of regular and blocking functions, and internally registers a -set of hooks which can be called by \aesop to make progress, test or cancel a +API consisting of regular and blocking functions. It internally registers a +set of hooks that can be called by \aesop to make progress, test, or cancel a blocking function exported by the resource API. Progress can be made by providing a polling function, which will be called by \aesop when no other work is available. Alternatively, at any time, a resource can asynchronously -request for its polling function to be called. However, \aesop does not +request its polling function to be called. However, \aesop does not enforce a progress model on the resource. Some resources do not define a polling function, typically because the resource or the underlying C library can make progress independently. hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 0d1347672166e05b7ec5f6338e7509d3122fc795
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

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 0d1347672166e05b7ec5f6338e7509d3122fc795 (commit) from 40274578c7b6ea7c7b8575cb0c88bbdb891ebd63 (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 0d1347672166e05b7ec5f6338e7509d3122fc795 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 20:49:25 2012 -0500 Gail edit: correct ordering of figures, eval sect ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 60 +++++++++++++++++++------------------- 1 files changed, 30 insertions(+), 30 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index e92b030..deefd3f 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -85,6 +85,32 @@ follows. %Each server is setup to report the VmHWM stat when the application exits. +\begin{figure*}[t] + \centering % + \subfloat[Write performance]{ + \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-ops.pdf} + \label{fig:write} + } + \subfloat[Read performance]{ + \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-ops.pdf} + \label{fig:read} + \vspace{-2ex} + } % + \par% + \vspace{-2ex}% + \subfloat[Write-null performance]{ + \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-null-ops.pdf} + \label{fig:writenull} + } % + \subfloat[Read-null performance]{ + \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-null-ops.pdf} + \label{fig:readnull} + } % + \caption{Run-time performance for each test case.\\ + \footnotesize (X-axis is the number of client instances, each graph has + a distinct Y-axis.)} +\end{figure*} + \paragraph*{\aesop} The \aesop server is implemented by using the \aesop programming language. A @@ -204,32 +230,6 @@ section that poor \aesop performance at small scale is likely a tuning flaw in the file resource used in the \aesop standard library, rather than a fundamental programming language problem. -\begin{figure*}[ht] - \centering % - \subfloat[Write performance]{ - \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-ops.pdf} - \label{fig:write} - } - \subfloat[Read performance]{ - \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-ops.pdf} - \label{fig:read} - \vspace{-2ex} - } % - \par% - \vspace{-2ex}% - \subfloat[Write-null performance]{ - \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-null-ops.pdf} - \label{fig:writenull} - } % - \subfloat[Read-null performance]{ - \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-null-ops.pdf} - \label{fig:readnull} - } % - \caption{Run-time performance for each test case.\\ - \footnotesize (X-axis is the number of client instances, each graph has - a distinct Y-axis.)} -\end{figure*} - The test client also measures the latency of each individual request and then computes the minimum and maximum latency, the first quartile latency, and the third @@ -244,7 +244,7 @@ asynchronous I/O implementation. As the latency numbers for the other request types show similar results, only the write test is shown. -\begin{figure}[ht] +\begin{figure}[t] \centering \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-lat.pdf} \caption{Write latency (1,024 clients).\label{fig:writelat}} @@ -278,7 +278,7 @@ relevant metric in practice. Since the memory usage for remaining tests (read, read-null, and write-null) was similar, only the write test results are shown. -\begin{figure}[ht] +\begin{figure}[t] \centering \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-mem.pdf} \caption{Write memory usage.\label{fig:writemem}} @@ -286,7 +286,7 @@ shown. \subsection{Productivity} -\begin{table} +\begin{table}[b] \small \begin{center} \caption{Complexity analysis for example servers} @@ -388,7 +388,7 @@ using the event or threaded models, since neither model offers any help in cancelling an outstanding call. \end{comment} % -%\begin{figure*}[ht] +%\begin{figure*}[t] %\hfill %\begin{minipage}[b]{.49\textwidth} % \begin{lstlisting}[caption={aesop code}, label=lst:aesop] hooks/post-receive -- Triton-private Repository

1 0