Triton-private Repository branch, master, updated. e8b5bb860e45d135b45133cfae137dca1071f2f3
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 e8b5bb860e45d135b45133cfae137dca1071f2f3 (commit) from 35ea611a5c4239d0daa62f3e8608fe8fbacbaa33 (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 e8b5bb860e45d135b45133cfae137dca1071f2f3 Author: Phil Carns <[email protected]> Date: Mon Mar 5 11:20:12 2012 -0500 minor edits to intro ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/intro.tex | 18 +++++++++++------- 1 files changed, 11 insertions(+), 7 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/intro.tex b/papers/2011/aesop/intro.tex index c520c3f..8c04208 100644 --- a/papers/2011/aesop/intro.tex +++ b/papers/2011/aesop/intro.tex @@ -39,21 +39,21 @@ 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 produces a natural, readable control flow in algorithm implementations -because each thread can execute sequentially and issue simple blocking -device operations. Threads also provide a clear, deterministic model +It produces a natural control flow in algorithm implementations +because each thread executes sequentially and issues simple blocking +device operations. Threads also provide a clear model to express concurrency. There are a number of challenges to building a multi-threaded service, however. The first is that it is not always intuitive how to best provision thread resources; threads can be assigned per client, per request, or per underlying device operation, and they may be allocated on demand or from an existing pool. Each technique or combination of techniques presents tradeoffs in scalability, performance, -and readability, yet it is often difficult to transition between them +and readability, yet it is difficult to transition between them during the development process. The second challenge is the disconnect between the number of threads needed to express logical concurrency and the number of threads needed to make optimal use of local resources. For example, even if there -are 1,000 client requests in flight at once, the server may only have a few +are 1,000 client requests in flight at once, the server may have only a few processing cores and a storage device that can only effectively handle a few operations at a time. This disconnect can cause a seemingly simple thread model to evolve into a more @@ -80,7 +80,7 @@ generalized. This makes it difficult to verify dependencies or perform type checking between states. Pure event-driven models also do not directly address the requirement of multi-core architectures or high performance peripherals that must use multiple threads to achieve maximize throughput. -Event-driven servers may therefore evolve during the development process to take on +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. @@ -104,7 +104,11 @@ tuned to match different system architectures, different device APIs, and different workloads without any change to the core system software algorithms. Unlike event-driven architectures, the \aesop extensions also preserve readable control flow regardless of how many steps or -concurrent devices are utilized in a given algorithm. +concurrent devices are utilized in a given algorithm. Aesop also offers +functionality that is simply not available in a traditional multithreaded or +event-driven framework, including the ability to mark variables as being +shared or private across concurrent execution paths as well as a robust +mechanism to cancel concurrent execution paths. \todo{Fill this in:} hooks/post-receive -- Triton-private Repository
participants (1)
-
noreply@mcs.anl.gov