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

Triton-private Repository branch, master, updated. 21370ccd7f4674b848e98e7ff895ca7bfe1b6dff
by noreply＠mcs.anl.gov 16 Mar '12

16 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 21370ccd7f4674b848e98e7ff895ca7bfe1b6dff (commit) from 2cb5b434e91a3dfcf5f221c1a83fa84ad5a5c46b (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 21370ccd7f4674b848e98e7ff895ca7bfe1b6dff Author: Justin M Wozniak <wozniak(a)mcs.anl.gov> Date: Fri Mar 16 16:53:22 2012 -0500 Use initial ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index ac273ef..f069603 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -91,7 +91,7 @@ xleftmargin=6ex \author{Dries Kimpe\inst{1} \and Philip Carns\inst{1} \and Kevin Harms\inst{1} -\and Justin Wozniak\inst{1} \and Samuel Lang\inst{1} \and Robert Ross\inst{1}} +\and Justin M. Wozniak\inst{1} \and Samuel Lang\inst{1} \and Robert Ross\inst{1}} % author names and affiliations % use a multiple column layout for up to two different hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 2cb5b434e91a3dfcf5f221c1a83fa84ad5a5c46b
by noreply＠mcs.anl.gov 16 Mar '12

16 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 2cb5b434e91a3dfcf5f221c1a83fa84ad5a5c46b (commit) from d71cd4c41957356f20cd8043238609b0d629b8a2 (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 2cb5b434e91a3dfcf5f221c1a83fa84ad5a5c46b Author: Justin M Wozniak <wozniak(a)mcs.anl.gov> Date: Fri Mar 16 16:47:36 2012 -0500 Minor changes ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/implementation.tex | 2 +- papers/2011/aesop/intro.tex | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/implementation.tex b/papers/2011/aesop/implementation.tex index d78fae6..ec9f1d1 100644 --- a/papers/2011/aesop/implementation.tex +++ b/papers/2011/aesop/implementation.tex @@ -58,7 +58,7 @@ 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 +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 diff --git a/papers/2011/aesop/intro.tex b/papers/2011/aesop/intro.tex index bc63da0..1bf6766 100644 --- a/papers/2011/aesop/intro.tex +++ b/papers/2011/aesop/intro.tex @@ -43,7 +43,7 @@ Thread scheduling and stack management are handled by the operating system. Building a multithreaded service raises a number of challenges, however. The first is determining how to provision thread resources. 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; 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 @@ -109,15 +109,15 @@ operations. The contributions of this paper can be summarized as follows: \begin{itemize} -\item Description of a new programming model and language, \aesop, +\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 +\item Definition of new language constructs to help manage highly concurrent execution \item Case study comparing \aesop to five popular multithreaded and event-driven architectures, using a simple distributed service as an example \item Quantitative analysis of the code complexity of the architectures -used in the case study +used in the case study \end{itemize} The remainder of this paper is organized as follows. hooks/post-receive -- Triton-private Repository

1 0

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

16 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 d71cd4c41957356f20cd8043238609b0d629b8a2 (commit) via 1b8b991a7b1cfe8675f5113c8b788fab52b63c54 (commit) via 745ae78939aac89e98bf8a3ec8e2de1652ee19cc (commit) via a05c5e60bb6427018f676acab8be4a6e85bb7f35 (commit) via 4f75fa6b9d5e319a1fac5d722c6cf0aee1d77eb9 (commit) from 8b83dbc762d6ba7de8b394c18d223e0ec58b2118 (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 d71cd4c41957356f20cd8043238609b0d629b8a2 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 16:44:58 2012 -0500 clarify system software commit 1b8b991a7b1cfe8675f5113c8b788fab52b63c54 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 16:44:49 2012 -0500 Restore pmccabe tool citation commit 745ae78939aac89e98bf8a3ec8e2de1652ee19cc Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 16:44:29 2012 -0500 Restart DB section for now commit a05c5e60bb6427018f676acab8be4a6e85bb7f35 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 16:44:14 2012 -0500 Make inline code macro use a plain font commit 4f75fa6b9d5e319a1fac5d722c6cf0aee1d77eb9 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 15:23:11 2012 -0500 Add code repo link ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 3 ++- papers/2011/aesop/conclusion.tex | 8 ++++++-- papers/2011/aesop/context.tex | 2 ++ papers/2011/aesop/evaluation.tex | 2 +- papers/2011/aesop/implementation.tex | 4 ++-- papers/2011/aesop/intro.tex | 3 ++- 6 files changed, 15 insertions(+), 7 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index 996c862..ac273ef 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -51,7 +51,8 @@ xleftmargin=6ex \hyphenation{op-tical net-works semi-conduc-tor} \DeclareRobustCommand{\code}[1] - {\lstinline[breaklines=true,basicstyle=\ttfamily]{#1}} + {\lstinline[breaklines=true,basicstyle=\ttfamily, + keywordstyle=,identifierstyle=]{#1}} %\newcommand{\todo}[1]{ {\textcolor{red} { TODO: #1 }}} \newcommand{\woz} [1] {\todo{ Wozniak: #1 }} diff --git a/papers/2011/aesop/conclusion.tex b/papers/2011/aesop/conclusion.tex index 51de97f..d78a12a 100644 --- a/papers/2011/aesop/conclusion.tex +++ b/papers/2011/aesop/conclusion.tex @@ -22,8 +22,9 @@ concurrent execution paths to dedicated operating system threads. When considering programmer productivity, \aesop performs equally well, mainly because it has been specifically designed to implement highly scalable distributed services. It reduces code complexity while also -offering advanced primitives such as cancellation of execution paths and -control of variable scope that are not available in any other system software +offering advanced primitives such as cancellation of execution paths +% and control of variable scope +that are not available in any other system software development environment. We will continue to evaluate and evolve the \aesop language as we use it @@ -33,6 +34,9 @@ One example, which exists in prototype form already, is a remote procedure call framework that uses \aesop to manage concurrent communication, timeout, and retry functionality in a transparent manner. We also plan to provide enhanced functionality for debugging \aesop functions. +\aesop, and the code used to evaluate its performance, is available online at +\url{http://trac.mcs.anl.gov/projects/aesop}. + %- Need to fix some parser issues %- Compilation speed diff --git a/papers/2011/aesop/context.tex b/papers/2011/aesop/context.tex index 5f22e15..ca11583 100644 --- a/papers/2011/aesop/context.tex +++ b/papers/2011/aesop/context.tex @@ -289,6 +289,8 @@ Databases are commonly used for file system metadata, where efficiency 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 %whether a diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 27c4f0f..c8ccda3 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -259,7 +259,7 @@ Table~\ref{tab:complexity} compares the code complexity of each server implemenation using McCabe Cyclomatic Complexity (CC)~\cite{mccabe}, Modified McCabe Cyclomatic Complexity (mod. CC), and Source Lines of Code (SLOC). The CC and Mod. CC metrics were measured by -using the pmccabe tool, version 2.6, created by Paul Bame\begin{comment}~\cite{pmccabe}\end{comment}; +using the pmccabe tool, version 2.6, created by Paul Bame~\cite{pmccabe}; the SLOC metrics were measured using the sloccount tool, version 2.26, created by David A. Wheeler\begin{comment}~\cite{sloccount}\end{comment}. diff --git a/papers/2011/aesop/implementation.tex b/papers/2011/aesop/implementation.tex index 46c84a7..d78fae6 100644 --- a/papers/2011/aesop/implementation.tex +++ b/papers/2011/aesop/implementation.tex @@ -8,7 +8,7 @@ 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{aesop} functions; all other code is passed through unmodified. - +% \begin{figure} %\vskip -0.25in \centering @@ -16,7 +16,7 @@ functions; all other code is passed through unmodified. \caption{Model of Aesop usage.\label{fig:model}} \vspace{-.2in} \end{figure} - +% Figure~\ref{fig:model} shows how an \code{aesop} function, \code{service_function}, is translated by the current version of the \aesop translator. As a first step, all \code{aesop} diff --git a/papers/2011/aesop/intro.tex b/papers/2011/aesop/intro.tex index 1bac600..bc63da0 100644 --- a/papers/2011/aesop/intro.tex +++ b/papers/2011/aesop/intro.tex @@ -26,7 +26,8 @@ in between. In some cases, the most efficient API is platform specific. This diversity makes it difficult to build algorithms that are portable and yet capable of leveraging each component in an optimal manner. -The two most common models for managing asynchronous activity are +The two most common models for managing asynchronous activity in system +software are multithreading and event-driven architectures. Examples of both can be found in various large-scale production services. The Apache web server advocates a multithreaded mode of operation for high-performance hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 8b83dbc762d6ba7de8b394c18d223e0ec58b2118
by noreply＠mcs.anl.gov 16 Mar '12

16 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 8b83dbc762d6ba7de8b394c18d223e0ec58b2118 (commit) from 2ca0da5600483990ccc57eb4dc1769c35c67a40f (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 8b83dbc762d6ba7de8b394c18d223e0ec58b2118 Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Fri Mar 16 15:12:01 2012 -0500 Removed citations for pmmcabe and sloccount ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 14b8eac..27c4f0f 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -259,9 +259,9 @@ Table~\ref{tab:complexity} compares the code complexity of each server implemenation using McCabe Cyclomatic Complexity (CC)~\cite{mccabe}, Modified McCabe Cyclomatic Complexity (mod. CC), and Source Lines of Code (SLOC). The CC and Mod. CC metrics were measured by -using the pmccabe tool, version 2.6, created by Paul Bame~\cite{pmccabe}; +using the pmccabe tool, version 2.6, created by Paul Bame\begin{comment}~\cite{pmccabe}\end{comment}; the SLOC metrics were measured using the sloccount tool, -version 2.26, created by David A. Wheeler~\cite{sloccount}. +version 2.26, created by David A. Wheeler\begin{comment}~\cite{sloccount}\end{comment}. In order to simplify the comparison, all four servers had no error handling except for assertions on expected return codes. The protocol definition as well as helper functions for sending hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 2ca0da5600483990ccc57eb4dc1769c35c67a40f
by noreply＠mcs.anl.gov 16 Mar '12

16 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 2ca0da5600483990ccc57eb4dc1769c35c67a40f (commit) via b6913e4b04377c8ae1a577feae8e50ba82f3ed45 (commit) from 18189596ad4c8da26e8cff3648effafdad27dcac (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 2ca0da5600483990ccc57eb4dc1769c35c67a40f Merge: b6913e4b04377c8ae1a577feae8e50ba82f3ed45 18189596ad4c8da26e8cff3648effafdad27dcac Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Fri Mar 16 14:38:37 2012 -0500 Merge branch 'master' of git.mcs.anl.gov:triton-private commit b6913e4b04377c8ae1a577feae8e50ba82f3ed45 Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Fri Mar 16 14:38:30 2012 -0500 Minor edits to evaluation secion to reduce length ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 22 ++++++++++------------ 1 files changed, 10 insertions(+), 12 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index ab45784..14b8eac 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -71,8 +71,7 @@ uses synchronous socket and file I/O functions. The thread-per-client-nb server is identical to the thread-per-client server except that it uses asynchronous socket calls in place of synchronous -socket calls and uses \code{poll()} to determine when a socket can make -progress. +socket calls. We implemented this version to isolate the performance impact of asynchronous socket access when all other factors remain equal. \paragraph*{Thread-per-operation} @@ -80,15 +79,14 @@ We implemented this version to isolate the performance impact of asynchronous so The thread-per-operation server uses an event loop to watch all client connections for activity. When a new request is available, a thread is spawned, and the request is handled completely from within that thread. -This implementation uses synchronous socket and file I/O functions. +%This implementation uses synchronous socket and file I/O functions. \paragraph*{Thread-pool} The thread-pool server is similar to the thread-per-operation server in that it uses an event loop to watch client connections for activity. However, instead of creating a new thread to service each request, the -connection is added to a queue. A fixed-size thread pool is then used to service -each request in the queue. +requests are serviced by a fixed-size thread pool. \paragraph*{Event} @@ -115,14 +113,14 @@ write-null and read-null tests. All experiments were executed on the Fusion cluster in the Argonne Laboratory Computing Resource Center. Fusion is an IBM iDataPlex dx360 -M2 system. It features 320 compute nodes, consisting of two Intel -Nehalem 2.6 GHz Xeon processors and 36 GB of RAM. The compute nodes have -hyper-threading disabled. The cluster has an InfiniBand QDR interconnect. Each -compute node also has a single SATA 7200 RPM hard disk for local scratch -storage. All disk I/O was performed by using the local scratch storage and -client/server communication was done over the IB network using IPoIB. We +M2 system with a QDR Infiniband interconnect featuring 320 compute nodes, +consisting of two Intel Nehalem 2.6 GHz Xeon processors and 36 GB of RAM. +%The compute nodes have hyper-threading disabled. +Each compute node also has a single SATA 7200 RPM hard disk for local scratch +storage, which was used for all disk I/O in the experiment. +Client/server communication was done over the IB network using IPoIB. We instantiated 16 clients processes per phyiscal node. The tests were executed -on 65 nodes; one server node and 1 to 64 client nodes. +on 65 nodes; one server node and 1-64 client nodes. \subsection{Run-time Efficiency} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 18189596ad4c8da26e8cff3648effafdad27dcac
by noreply＠mcs.anl.gov 16 Mar '12

16 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 18189596ad4c8da26e8cff3648effafdad27dcac (commit) from 19a570c45c61687dd8d1655e2b1118a9cfa54d77 (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 18189596ad4c8da26e8cff3648effafdad27dcac Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 14:29:09 2012 -0500 Finished evaluation fixes ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 8e332eb..ab45784 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -208,8 +208,8 @@ amount of paged-in memory used by the executable. In Figure~\ref{fig:writemem} we see that the thread-pool server manages to limit the memory usage even though the client work load increases. This result can be -explained by the design of the thread-pool, which by limiting the number of -active threads used to service client connections also limits the number of +explained by the design of the thread-pool; by limiting the number of +active threads used to service client connections, it also limits the number of concurrent requests. For the other server implementations, memory usage increases accordingly as the number of concurrent requests increases. Although the \aesop server cannot match the thread-pool @@ -235,7 +235,7 @@ shown. \begin{table}[b] \small \begin{center} -\caption{Complexity analysis for example servers} +\caption{Code complexity analysis} \begin{tabular}{lrrr} \hline & CC & mod. CC & SLOC \\ @@ -276,7 +276,7 @@ create and join threads. The thread pool and event model implementation are both much more complex than the thread or \aesop model. An additional complexity of the event model -that +which is not captured by these metrics is that control flow is not preserved across the processing of a given request. For example, servicing a write operation requires five disconnected event handlers. @@ -311,7 +311,7 @@ handle multiple connections concurrently. \end{comment} The example server used for evaluation is simple and differs from real-world -code by the absence of error handling and time-out handling. As shown in Section~\ref{sec:example}, \aesop provides powerful +code by the absence of error handling and time-out handling. As described in Section~\ref{sec:example}, \aesop provides powerful primitives to simplify these activities. The same cannot be said of the event or threaded models, since neither model offers any help in cancelling an outstanding operation. hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 19a570c45c61687dd8d1655e2b1118a9cfa54d77
by noreply＠mcs.anl.gov 16 Mar '12

16 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 19a570c45c61687dd8d1655e2b1118a9cfa54d77 (commit) from 1cd0e83a84f70da025f1194caa850fbf28e58518 (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 19a570c45c61687dd8d1655e2b1118a9cfa54d77 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 14:24:35 2012 -0500 Fixes in evaluation ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 15 +++++++-------- 1 files changed, 7 insertions(+), 8 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 19d8cf5..8e332eb 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -129,20 +129,19 @@ on 65 nodes; one server node and 1 to 64 client nodes. Figure~\ref{fig:write} shows the request servicing rate of the concurrent write workload for each server implementation as the number of client processes is scaled from 16 to 1,024. In this graph we see that {\aesop} does not -perform as well as the other servers for small workloads (delivering 79 +perform as well as the other servers for a small number of clients (delivering 79 operations per second at the smallest scale, versus 132 ops/s for the thread-per-op server). However, {\aesop} is the fastest server at the largest scale (136 ops/s versus 125 ops/s for the nearest competitors in thread-per-client and thread-per-client-nb). - -Figure~\ref{fig:read} shows the results of the read experiment. \aesop -performs more favorably at small scale for this workload than in the -write workload. At the largest scale, \aesop completes the +When reading (Figure~\ref{fig:read}), +\aesop +performs more favorably at small scale. +At the largest scale, \aesop completes the test with 339 ops/s versus 354 ops/s for the fastest server (thread-pool), a 4.5\% difference. The event server performs particularly poorly in all cases, ultimately running the largest-scale test with only 212 ops/s. - The small-scale results for \aesop may indicate that additional tuning is needed to improve latency for small test runs. The issue is likely isolated to the write path of the file I/O resource in the \aesop standard @@ -183,11 +182,11 @@ the request latency for 1,024 clients for the write test. Each box represents th whiskers are the minimum and maximum values. From the figure, one can see that the \aesop server implementation exhibits similar latency results when compared to the other implementations. The -event server variant performs significantly worse, +event server variant shows significantly higher latency, however. This is likely an artifact of the Linux asynchronous I/O implementation. As the latency numbers for the other request types show similar results, only the -write test is shown. +write test results are shown. \begin{figure}[t] \centering hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 1cd0e83a84f70da025f1194caa850fbf28e58518
by noreply＠mcs.anl.gov 16 Mar '12

16 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 1cd0e83a84f70da025f1194caa850fbf28e58518 (commit) from fb4b88cb2f3024332b83e09411202ba2ec17b1ce (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 1cd0e83a84f70da025f1194caa850fbf28e58518 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 14:05:32 2012 -0500 Fixes in implementation; Removed unneeded detail ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/implementation.tex | 26 ++++++++++++++------------ 1 files changed, 14 insertions(+), 12 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/implementation.tex b/papers/2011/aesop/implementation.tex index 92bf9c0..46c84a7 100644 --- a/papers/2011/aesop/implementation.tex +++ b/papers/2011/aesop/implementation.tex @@ -21,7 +21,7 @@ Figure~\ref{fig:model} shows how an \code{aesop} function, \code{service_function}, is translated by the current version of the \aesop translator. As a first step, all \code{aesop} function calls within the function body are located. Based on the -location of the \code{aesop} calls, the function is effectively split in a +location of the \code{aesop} calls, the function is split into a set of code blocks (states), where each code block contains only nonblocking (traditional C) function calls. The calls themselves are rewritten in an asynchronous form. For @@ -34,22 +34,22 @@ injects a callback argument that indicates where execution should 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 starting point of an \aesop +might unwind all the way back to the 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. Once an operation completes, \aesop invokes its callback function to resume execution of the next code block. -Our current translator does not actually split an \code{aesop} function into -multiple independent functions. Instead, the function signature is modified -(to add the context and other internal parameters), and a jump table is -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 -an \code{aesop} call). These modifications enable the function to be -continued at the appropriate location once its execution can be -resumed. +%Our current translator does not actually split an \code{aesop} function into +%multiple independent functions. Instead, the function signature is modified +%(to add the context and other internal parameters), and a jump table is +%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 +%an \code{aesop} 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 @@ -72,6 +72,8 @@ current context. To do so, \aesop needs to know, for each \code{aesop} call, how to cancel the operation. For functions translated by \aesop (those marked by \code{aesop}), \aesop internally provides the cancel methods. + +% resources 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}. Resources are typically used to provide an hooks/post-receive -- Triton-private Repository

1 0

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

16 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 fb4b88cb2f3024332b83e09411202ba2ec17b1ce (commit) from 0875683647b47cc9a2bf5ac4350d80f564cea944 (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 fb4b88cb2f3024332b83e09411202ba2ec17b1ce Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Fri Mar 16 13:55:58 2012 -0500 model fixes ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/model.tex | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/model.tex b/papers/2011/aesop/model.tex index 247a2f6..5d54492 100644 --- a/papers/2011/aesop/model.tex +++ b/papers/2011/aesop/model.tex @@ -114,7 +114,7 @@ language, a proper \code{aesop} function should return as soon as 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 +The intention is that functions that are not completely CPU-bound (i.e., cannot efficiently fully consume a thread) are to be \code{aesop} functions. \aesop detects when a \code{aesop} function can no longer make progress (for example, because the function is waiting @@ -186,7 +186,7 @@ to a request, cancelling the request when the allocated time is exceeded. In the code example, \code{write} concurrently forwards the write operation to -\code{REPLICAS} replicas. This is done using a for loop containing a pbranch. +\code{REPLICAS} replicas. This is implemented using a \code{for} loop containing a pbranch. 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 @@ -197,13 +197,15 @@ 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} to complete, the timer (line 11) will complete first, causing the ongoing -\code{doReplicaWrite} operation to be cancelled. Note how \code{replicaWrite}, +\code{doReplicaWrite} operation to be cancelled. The \code{ae_cancel_branches} +call internally synchronizes, preventing both branches from cancelling each +other. Note how \code{replicaWrite}, 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 +The short code fragment from Listing~\ref{lst:parallelfor} +implements 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. +can be executed concurrently, with each write operation protected by a timeout. hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 0875683647b47cc9a2bf5ac4350d80f564cea944
by noreply＠mcs.anl.gov 16 Mar '12

16 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 0875683647b47cc9a2bf5ac4350d80f564cea944 (commit) from 03f62e1960627e6591c4826e326c0dc0a043337a (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 0875683647b47cc9a2bf5ac4350d80f564cea944 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Fri Mar 16 13:29:20 2012 -0500 cut one word to make later headings line up ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/related.tex | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/related.tex b/papers/2011/aesop/related.tex index 6115589..b7b4474 100644 --- a/papers/2011/aesop/related.tex +++ b/papers/2011/aesop/related.tex @@ -55,7 +55,7 @@ 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. The developer is left the task of fitting their -algorithm logic to the basic event-driven model. +algorithm logic to the event-driven model. The \aesop language described in this work builds on lessons learned from hooks/post-receive -- Triton-private Repository

1 0