Index: libs/interprocess/doc/interprocess.qbk
===================================================================
--- libs/interprocess/doc/interprocess.qbk	(revision 49440)
+++ libs/interprocess/doc/interprocess.qbk	(working copy)
@@ -1516,11 +1516,11 @@
 can do two things:
 
 *  [*wait]: The thread is blocked until some other thread notifies that it can
-   continue because the condition that lead to waiting has disapeared.
+   continue because the condition that lead to waiting has disappeared.
 
 *  [*notify]: The thread sends a signal to one blocked thread or to all blocked
    threads to tell them that they the condition that provoked their wait has
-   disapeared.
+   disappeared.
 
 Waiting in a condition variable is always associated with a mutex. 
 The mutex must be locked prior to waiting on the condition. When waiting
@@ -2178,7 +2178,7 @@
 A lock transfer operations explicitly indicates that a mutex owned by a lock is
 transferred to another lock executing atomic unlocking plus locking operations.
 
-[section:lock_trnasfer_simple_transfer Simple Lock Transfer]
+[section:lock_transfer_simple_transfer Simple Lock Transfer]
 
 Imagine that a thread modifies some data in the beginning but after that, it has to 
 just read it in a long time. The code can acquire the exclusive lock, modify the data
@@ -3668,10 +3668,10 @@
 As mentioned, the managed segment stores the information about named and unique
 objects in two indexes. Depending on the type of those indexes, the index must
 reallocate some auxiliary structures when new named or unique allocations are made.
-For some indexes, if the user knows how many maned or unique objects is going to
-create it's possible to preallocate some structures to obtain much better
-performance (if the index is an ordered vector it can  preallocate memory to avoid
-reallocations, if the index is a hash structure it can preallocate the bucket array...).
+For some indexes, if the user knows how many named or unique objects are going to
+be created, it's possible to preallocate some structures to obtain much better
+performance. (If the index is an ordered vector it can  preallocate memory to avoid
+reallocations. If the index is a hash structure it can preallocate the bucket array.)
 
 The following functions reserve memory to make the subsequent allocation of
 named or unique objects more efficient. These functions are only useful for
@@ -5671,7 +5671,7 @@
 [section:basic_guidelines Basic guidelines]
 
 When building [*Boost.Interprocess] architecture, I took some basic guidelines that can be
-resumed in these points:
+summarized by these points:
 
 *  [*Boost.Interprocess] should be portable at least in UNIX and Windows systems. That
    means unifying not only interfaces but also behaviour. This is why