Pass 2

[Ben Hutchings]

I've made a few fixes and am attaching a diff.  The fixes cover

- typos
- grammar/editing errors
- use of the term "memory barriers" without explanation
- correction of names
  - "PowerPC", not "powerpc"
  - "POSIX threads", not the redundant "POSIX pthreads"
- hyphenation

The last of these might be slightly contentious.  I removed the hyphen
from "multi-threading" in the abstract since it is used without a
hyphen later on.  If this inconsistency was deliberate, please ignore
the change.  In other places I have added hyphens where I think the
joining of words is obscure: "multi-core", "inter-thread".

I seem to remember that TeX treats hyphens as soft by default, in
which case I think some of the hyphens ought to be made hard.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.
-------------- next part --------------
--- multithreading.tex.orig	Fri Sep 10 15:10:52 2004
+++ multithreading.tex	Fri Sep 10 15:30:57 2004
@@ -27,7 +27,7 @@
 \begin{abstract} 
 
 The C++ Standard defines single-threaded program execution. Fundamentally,
-multi-threaded execution requires a much more refined memory and execution
+multithreaded execution requires a much more refined memory and execution
 model. C++ threading libraries are in the awkward situation of specifying
 (implicitly or explicitly) an extended memory model for C++ in order to specify
 program execution. We propose integrating a memory model suitable for
@@ -40,7 +40,7 @@
 
 Many of today's applications make use of multithreaded execution. We
 expect such use to grow as the increased use of hardware
-multithreading (a.k.a. ``hyperthreading'') and multicore processors
+multithreading (a.k.a. ``hyperthreading'') and multi-core processors
 will force or entice more and more applications to become
 multithreaded.  C++ is commonly used as part of multithreaded
 applications, sometimes with either direct calls into an OS-provided
@@ -69,11 +69,11 @@
 uses can fail unexpectedly due to unforeseen compiler
 optimizations. These optimizations are safe in a single-threaded
 context, but not with multiple threads.  Additionally, the
-specification does not address at all the interations of memory
+specification does not address at all the interactions of memory
 operations with atomic update operations or constructs such as locks
 built out of them. (The pthreads spec does not help much here, since
 lock semantics are not fully backwards-integrated with the semantics
-of other memory operations).
+of other memory operations.)
 
 These problems can be solved without introducing additional keywords
 or syntactic constructs. The main plan of attack is:
@@ -81,7 +81,7 @@
 \begin{enumerate}
 
 \item Specification of an abstract memory model describing the
-interactions between threads and memory. .
+interactions between threads and memory.
 
 \item Application of this model to existing aspects of the C++
 specification to replace the current implicitly sequential
@@ -106,7 +106,7 @@
 \end{enumerate}
 
 This is an ambitious proposal, and the current draft represents only
-the first steps of the standarization process. In the remainder of
+the first steps of the standardization process. In the remainder of
 this draft, we briefly describe the basic issues, some concrete
 steps in addressing them, and sketch out remaining work.
 
@@ -132,13 +132,13 @@
 underlying the revised Java Memory Model specification \cite{JSR133}
 and related efforts have resulted in models that can be readily
 applied to C++. We anticipate that this part of the specification will
-mainly be a matter of adapting, not creating a formal model.
+mainly be a matter of adapting, not creating, a formal model.
 
 \section{Memory Effects}
 
 A memory model defines categories of memory actions, for example those
 that act as {\em acquire} and {\em release} operations guarantee
-visibility of set of updates by one thread to another. The next step
+visibility of a set of updates by one thread to another. The next step
 for a language specification is to map these notions to all of the
 memory-related constructions in the language. This process entails
 nailing down a large set of ``small issues'' that are necessary 
@@ -156,7 +156,7 @@
 not obvious from inspection of source code. The most notable
 examples involve ``word tearing''. For example, in:
 \begin{verbatim}
-struct S { short a; char b; char c };
+struct S { short a; char b; char c } s;
 \end{verbatim}
 
 an assignment such as {\tt s.a = 0} might be executed as if it were
@@ -171,7 +171,7 @@
 semantics; for example for device control registers as well as to
 indicate opaque flow (as in {\tt setjmp}). In a multithreaded
 language, {tt volatile} has the extra burden of constraining
-interthread visibility and ordering properties. There are a few
+inter-thread visibility and ordering properties. There are a few
 options for the detailed semantics. In the simplest, {\tt volatile}
 reads act as {\em acquire} and writes as {\em release}. This has the
 virtue of being relatively easy to use by programmers who are not
@@ -179,13 +179,13 @@
 ``double-checked locking'' idiom works as expected under these rules
 if references are declared as {\tt volatile} (and other lock-based
 rules (below) are followed).  This has the disadvantage of
-imposing ``heavier'' compiler constraints and processor memory
-barriers than necessary in some applications. However, this tactic 
+imposing ``heavier'' constraints on the compiler and processor
+than necessary in some applications. However, this tactic 
 might still suffice if weaker forms are also provided, as discussed
 in the next section.
 
 \item[Opaque calls] One of the concerns about multithreaded
-specifications is that compilers may become overly conservative
+specifications is that compilers may become overly conservative when
 compiling code with opaque function calls -- flushing and reloading
 registers and/or issuing memory barriers in case the called function's
 effects depend on this. It may be desirable to allow programmers to
@@ -193,10 +193,10 @@
 defaults in both directions; for example, assuming lack of effects
 unless a function is qualified as, say {\tt mutable}; versus assuming
 effects unless qualified with some extended form of {\tt
-const}. Alternatives, or in addition, the spec could include a means
+const}. Alternatively, or in addition, the spec could include a means
 for programmers to tell compilers that a certain program is either
-definitely single-threaded or defintitely multithreaded, as a way of
-controlling certin optimizations. Further exploration of options and
+definitely single-threaded or definitely multithreaded, as a way of
+controlling certain optimizations. Further exploration of options and
 their consequences is needed.
 
 
@@ -205,9 +205,10 @@
 \section{Atomics}
 
 Atomic update operations (as well as associated memory barrier
-instructions) form the basis for essentially all modern multithreaded
+instructions, which impose memory ordering constraints on the
+processor) form the basis for essentially all modern multithreaded
 synchronization and coordination. While there is some diversity across
-machines systems in the nature and style of these instructions, there
+architectures in the nature and style of these instructions, there
 is enough commonality in current and medium-term-future systems to
 define a small set of intrinsics that can be used for portable
 concurrent programming. There are several stylistic options here.  The
@@ -237,11 +238,11 @@
 The main attraction of this approach is that it appears to be
 implementable on essentially any platform. Even those machines without
 such primitives can emulate them private using locks. And even though
-some machines (such as powerpc) support LL/SC ({\em load-linked,
+some machines (such as PowerPC) support LL/SC ({\em load-linked,
 store-conditional}) instead of CAS ({\em compareAndSet}, in practice,
 nearly all usages of LL/SC are to perform CAS (the reverse is
 impossible), so there would rarely be motivation to resort to
-non-standarized, non-portable constructions even on these platforms.
+non-standardized, non-portable constructions even on these platforms.
 
 The idea of the ``weak'' versions is to permit finer control of
 atomics and barriers than otherwise available using {\tt volatile} or
@@ -254,7 +255,7 @@
 
 Currently, multithreaded C++ programs tend to rely primarily on one of
 fairly small set of libraries for threading support: mainly POSIX
-pthreads, WIN32, ACE, and Boost. These possess many more similarities
+threads, Win32, ACE, and Boost. These possess many more similarities
 than differences. The opportunity arises to provide a standard
 library that conservatively abstracts over such packages. 
 
@@ -267,7 +268,7 @@
 
 In this draft we do not even sketch out the APIs of this library. A
 future draft will include proposed classes developed with the
-involvment and feedback from users and developers of existing
+involvement and feedback from users and developers of existing
 libraries.
 
 \bibliography{multithreading}