minor typographical

Signed-off-by: kay <[email protected]>

Author: milkie

source/faq/concurrency.txt

@@ -31,7 +31,7 @@ What type of locking does MongoDB use?
 In addition to a shared (S) locking mode for reads and an exclusive
 (X) locking mode for write operations, intent shared (IS) and intent
 exclusive (IX) modes indicate an intent to read or write a resource
-using a finer granularity lock.  When locking at a certain granularity
+using a finer granularity lock.  When locking at a certain granularity,
 all higher levels are locked using an :term:`intent lock`.
 
 For example, when locking a collection for writing (using mode X),
@@ -172,7 +172,7 @@ of a :term:`replica set`, take the :program:`mongod` offline and let
 other members of the set service load while maintenance is in progress.
 
 The following administrative operations require an exclusive
-(i.e. write) lock on the database for extended periods:
+lock at the database level for extended periods:
 
 - :method:`db.collection.createIndex()`, when issued
   *without* setting ``background`` to ``true``,
@@ -312,11 +312,11 @@ Can reads see changes that have not been committed to disk?
 
 .. versionchanged:: 3.2
 
-   MongoDB 3.2 introduces :ref:`3.2-rel-notes-readConcern` option.
+   MongoDB 3.2 introduced the :ref:`3.2-rel-notes-readConcern` option.
    Clients using :readconcern:`majority` ``readConcern`` cannot see the
    results of writes before they are made :term:`durable`.
 
-Readers, using :readconcern:`"local"` ``readConcern`` can see the
+Readers using :readconcern:`"local"` ``readConcern`` can see the
 results of writes before they are made :term:`durable`, regardless of
 write concern level or journaling configuration. As a result,
 applications may observe the following behaviors: