Merge pull request #212 from alexwlchan/master

Spelling fixes

Author: mgravell

Docs/Basics.md

@@ -35,7 +35,7 @@ The object returned from `GetDatabase` is a cheap pass-thru object, and does not
     object asyncState = ...
     IDatabase db = redis.GetDatabase(databaseNumber, asyncState);
 
-Once you have the `IDatabase`, it is simply a case of using the [redis API](http://redis.io/commands). Note that all methods have both synchronous and asynchronous implementaions. In line with Microsoft's naming guidance, the asynchronous methods all end `...Async(...)`, and are fully `await`-able etc.
+Once you have the `IDatabase`, it is simply a case of using the [redis API](http://redis.io/commands). Note that all methods have both synchronous and asynchronous implementations. In line with Microsoft's naming guidance, the asynchronous methods all end `...Async(...)`, and are fully `await`-able etc.
 
 The simplest operation would be to store and retrieve a value:
 
@@ -100,12 +100,12 @@ There are 3 primary usage mechanisms with StackExchange.Redis:
 - Asynchronous - where the operation completes some time in the future, and a `Task` or `Task<T>` is returned immediately, which can later:
  - be `.Wait()`ed (blocking the current thread until the response is available)
  - have a continuation callback added ([`ContinueWith`](http://msdn.microsoft.com/en-us/library/system.threading.tasks.task.continuewith(v=vs.110).aspx) in the TPL)
- - be *awaited* (which is a language-level feature that simplfies the latter, while also continuing immediately if the reply is already known)
+ - be *awaited* (which is a language-level feature that simplifies the latter, while also continuing immediately if the reply is already known)
 - Fire-and-Forget - where you really aren't interested in the reply, and are happy to continue irrespective of the response
 
 The synchronous usage is already shown in the examples above. This is the simplest usage, and does not involve the [TPL][1].
 
-For asynchronous uage, the key difference is the `Async` suffix on methods, and (typically) the use of the `await` language feature. For example:
+For asynchronous usage, the key difference is the `Async` suffix on methods, and (typically) the use of the `await` language feature. For example:
 
     string value = "abcdefg";
     await db.StringSetAsync("mykey", value);

Docs/Configuration.md

@@ -10,7 +10,7 @@ The `configuration` here can be either:
 - a `ConfigurationOptions` instance
 - a `string` representing the configuration
 
-The latter is *basically* a tokenized form of the former. 
+The latter is *basically* a tokenized form of the former.
 
 Basic Configuration Strings
 -
@@ -56,7 +56,7 @@ The `ConfigurationOptions` object has a wide range of properties, all of which a
 | name={string}          | `ClientName`           | Identification for the connection within redis                                  |
 | password={string}      | `Password`             | Password for the redis server                                                   |
 | proxy={proxy type}     | `Proxy`                | Type of proxy in use (if any); for example "twemproxy"                          |
-| resolveDns={bool}      | `ResolveDns`           | Specifies that DNS resolution should be explict and eager, rather than implicit |
+| resolveDns={bool}      | `ResolveDns`           | Specifies that DNS resolution should be explicit and eager, rather than implicit |
 | serviceName={string}   | `ServiceName`          | Not currently implemented (intended for use with sentinel)                      |
 | ssl={bool}             | `Ssl`                  | Specifies that SSL encryption should be used                                    |
 | sslHost={string}       | `SslHost`              | Enforces a particular SSL host identity on the server's certificate             |

Docs/KeysValues.md

@@ -93,4 +93,4 @@ The response uses the `RedisResult` type (this is unique to scripting; usually t
 Conclusion
 ---
 
-The types used in the API are very deliberately chosen to distinguish redis *keys* from *values*. However, in virtually all cases you will not need to directly refer to the unerlying types involved, as conversion operations are provided.
+The types used in the API are very deliberately chosen to distinguish redis *keys* from *values*. However, in virtually all cases you will not need to directly refer to the underlying types involved, as conversion operations are provided.

Docs/PipelinesMultiplexers.md

@@ -76,7 +76,7 @@ For this reason, the only redis features that StackExchange.Redis does not offer
 This achieves the same intent without requiring blocking operations. Notes:
 
 - the *data* is not sent via pub/sub; the pub/sub API is only used to notify workers to check for more work
-- if there are no workers, the new items remain buffered in the lsit; work does not fall on the floor
+- if there are no workers, the new items remain buffered in the list; work does not fall on the floor
 - only one worker can pop a single value; when there are more consumers than producers, some consumers will be notified and then find there is nothing to do
 - when you restart a worker, you should *assume* there is work so that you process any backlog
 - but other than that, the semantic is identical to blocking pops

Docs/Profiling.md

@@ -43,7 +43,7 @@ Due to StackExchange.Redis's asynchronous interface, profiling requires outside
 by providing context objects when you start and end profiling (via the `BeginProfiling(object)` & `FinishProfiling(object)` methods), and when a
 command is sent (via the `IProfiler` interface's `GetContext()` method).
 
-A toy example of assocating commands issued from many different threads together
+A toy example of associating commands issued from many different threads together
 
 ```
 class ToyProfiler : IProfiler

Docs/Transactions.md

@@ -2,12 +2,12 @@
 =====================
 
 Transactions in Redis are not like transactions in, say a SQL database. The [full documentation is here](http://redis.io/topics/transactions),
-but to paraphraise:
+but to paraphrase:
 
 A transaction in redis consists of a block of commands placed between `MULTI` and `EXEC` (or `DISCARD` for rollback). Once a `MULTI`
 has been encountered, the commands on that connection *are not executed* - they are queued (and the caller gets the reply `QUEUED`
 to each). When an `EXEC` is encountered, they are
-all applied in a single unit (i.e. without other connections getting time betweeen operations). If a `DISCARD` is seen instead of 
+all applied in a single unit (i.e. without other connections getting time between operations). If a `DISCARD` is seen instead of 
 a `EXEC`, everything is thrown away. Because the commands inside the transaction are queued, you can't make decisions *inside*
 the transaction. For example, in a SQL database you might do the following (pseudo-code - illustrative only):