Index: boost/atomic/detail/gcc-armv6plus.hpp =================================================================== --- boost/atomic/detail/gcc-armv6plus.hpp (revision 82061) +++ boost/atomic/detail/gcc-armv6plus.hpp (working copy) @@ -57,7 +57,7 @@ // indicates the mode, so 1 is added to indicate that the destination code is Thumb. // A temporary register is needed for the address and is passed as an argument to these // macros. It must be one of the "low" registers accessible to Thumb code, specified -// usng the "l" attribute in the asm statement. +// using the "l" attribute in the asm statement. // // Architecture v7 introduces "Thumb 2", which does include (almost?) all of the ARM // instruction set. So in v7 we don't need to change to ARM mode; we can write "universal Index: boost/atomic/detail/gcc-ppc.hpp =================================================================== --- boost/atomic/detail/gcc-ppc.hpp (revision 82061) +++ boost/atomic/detail/gcc-ppc.hpp (working copy) @@ -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 Index: boost/atomic/detail/linux-arm.hpp =================================================================== --- boost/atomic/detail/linux-arm.hpp (revision 82061) +++ boost/atomic/detail/linux-arm.hpp (working copy) @@ -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. // Index: libs/atomic/test/atomicity.cpp =================================================================== --- libs/atomic/test/atomicity.cpp (revision 82061) +++ libs/atomic/test/atomicity.cpp (working copy) @@ -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 Index: libs/atomic/doc/platform.qbk =================================================================== --- libs/atomic/doc/platform.qbk (revision 82061) +++ libs/atomic/doc/platform.qbk (working copy) @@ -68,7 +68,7 @@ Some amount of care must be taken as the "raw" data type passed in from the user through [^boost::atomic] 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 @@ [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 Index: libs/atomic/doc/atomic.hpp =================================================================== --- libs/atomic/doc/atomic.hpp (revision 82061) +++ libs/atomic/doc/atomic.hpp (working copy) @@ -142,7 +142,7 @@ 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 @@ \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 @@ 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 @@ \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 Index: libs/atomic/doc/atomic.qbk =================================================================== --- libs/atomic/doc/atomic.qbk (revision 82061) +++ libs/atomic/doc/atomic.qbk (working copy) @@ -115,7 +115,7 @@ [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 @@ 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 @@ 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` results +* [*Using non-POD-classes as template parameter to `atomic` 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 @@ 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