atomic: merge fixes from trunk

[SVN r82074]

doc/atomic.hpp

@@ -142,7 +142,7 @@ public:
         implement the operation).
 
         The established memory order will be @c order if the operation
-        is successful. If the operation is unsuccesful, the
+        is successful. If the operation is unsuccessful, the
         memory order will be
 
         - @c memory_order_relaxed if @c order is @c memory_order_acquire ,
@@ -162,7 +162,7 @@ public:
         \param desired Desired new value
         \param success_order Memory ordering constraint if operation
         is successful
-        \param failure_order Memory ordering constraint if operation is unsuccesful
+        \param failure_order Memory ordering constraint if operation is unsuccessful
         \return @c true if value was changed
 
         Atomically performs the following operation
@@ -215,7 +215,7 @@ public:
         where feasible.
 
         The established memory order will be @c order if the operation
-        is successful. If the operation is unsuccesful, the
+        is successful. If the operation is unsuccessful, the
         memory order will be
 
         - @c memory_order_relaxed if @c order is @c memory_order_acquire ,
@@ -235,7 +235,7 @@ public:
         \param desired Desired new value
         \param success_order Memory ordering constraint if operation
         is successful
-        \param failure_order Memory ordering constraint if operation is unsuccesful
+        \param failure_order Memory ordering constraint if operation is unsuccessful
         \return @c true if value was changed
 
         Atomically performs the following operation

doc/atomic.qbk

@@ -115,7 +115,7 @@ look at the discussion of the correctness of a few of the
 
 [section:mutex Enforcing ['happens-before] through mutual exclusion]
 
-As an introductury example to understand how arguing using
+As an introductory example to understand how arguing using
 ['happens-before] works, consider two threads synchronizing
 using a common mutex:
 
@@ -142,7 +142,7 @@ One can however also arrive at the same conclusion using
 at [^m.lock()]. If this is be thread1, then as a consequence,
 thread2 cannot succeed at [^m.lock()] before thread1 has executed
 [^m.unlock()], consequently A ['happens-before] B in this case.
-By symmetry, if thread2 suceeds at [^m.unlock()] first, we can
+By symmetry, if thread2 succeeds at [^m.unlock()] first, we can
 conclude B ['happens-before] A.
 
 Since this already exhausts all options, we can conclude that
@@ -628,7 +628,7 @@ While [*Boost.Atomic] strives to implement the atomic operations
 from C++11 as faithfully as possible, there are a few
 limitations that cannot be lifted without compiler support:
 
-* [*Using non-POD-classes as template paramater to `atomic<T>` results
+* [*Using non-POD-classes as template parameter to `atomic<T>` results
   in undefined behavior]: This means that any class containing a
   constructor, destructor, virtual methods or access control
   specifications is not a valid argument in C++98. C++11 relaxes
@@ -666,7 +666,7 @@ implementation behaves as expected:
   of [*Boost.Atomic] compiles and has correct value semantics.
 * [*native_api.cpp] verifies that all atomic operations have correct
   value semantics (e.g. "fetch_add" really adds the desired value,
-  returing the previous). It is a rough "smoke-test" to help weed
+  returning the previous). It is a rough "smoke-test" to help weed
   out the most obvious mistakes (for example with overflow,
   signed/unsigned extension, ...).
 * [*lockfree.cpp] verifies that the [*BOOST_ATOMIC_*_LOCKFREE] macros

doc/platform.qbk

@@ -68,7 +68,7 @@ underlying class:
   Some amount of care must be taken as the "raw" data type
   passed in from the user through [^boost::atomic<T>]
   is visible here -- it thus needs to be type-punned or otherwise
-  manipulated byte-by-byte to avoid using overloaded assigment,
+  manipulated byte-by-byte to avoid using overloaded assignment,
   comparison operators and copy constructors.
 
 [endsect]
@@ -302,7 +302,7 @@ function in the following way:
 [section:platform_atomic_puttogether Putting it altogether]
 
 The template specializations should be put into a header file
-in the [^boost/atomic/detail] directory, preferrably
+in the [^boost/atomic/detail] directory, preferably
 specifying supported compiler and architecture in its name.
 
 The file [^boost/atomic/detail/platform.hpp] must

include/boost/atomic/detail/gcc-ppc.hpp

@@ -48,7 +48,7 @@
     it that values carried in registers are extended appropriately and
     everything falls into place naturally).
 
-    The register constrant "b"  instructs gcc to use any register
+    The register constraint "b"  instructs gcc to use any register
     except r0; this is sometimes required because the encoding for
     r0 is used to signify "constant zero" in a number of instructions,
     making r0 unusable in this place. For simplicity this constraint

include/boost/atomic/detail/linux-arm.hpp

@@ -14,7 +14,7 @@
 // Intel/Marvell XScale chips like the one in the NSLU2) have only atomic swap.
 // On Linux the kernel provides some support that lets us abstract away from
 // these differences: it provides emulated CAS and barrier functions at special
-// addresses that are garaunteed not to be interrupted by the kernel.  Using
+// addresses that are guaranteed not to be interrupted by the kernel.  Using
 // this facility is slightly slower than inline assembler would be, but much
 // faster than a system call.
 //

test/atomicity.cpp

@@ -21,7 +21,7 @@
 // we get 0.995 probability to detect a race (if there is one).
 //
 // Overall this yields 0.995 * 0.995 > 0.99 confidence that the
-// operations truely behave atomic if this test program does not
+// operations truly behave atomic if this test program does not
 // report an error.
 
 #include <algorithm>