Fix wiki-style doc tags. StephenCleary#72

Author: StephenCleary

doc/AsyncAutoResetEvent.md

@@ -1,15 +1,15 @@
 ## Overview
 
-This is the `async`-ready equivalent of [[AutoResetEvent|https://docs.microsoft.com/en-us/dotnet/api/system.threading.autoresetevent]], similar to Stephen Toub's [[AsyncAutoResetEvent|https://blogs.msdn.microsoft.com/pfxteam/2012/02/11/building-async-coordination-primitives-part-2-asyncautoresetevent/]].
+This is the `async`-ready equivalent of [AutoResetEvent](https://docs.microsoft.com/en-us/dotnet/api/system.threading.autoresetevent), similar to Stephen Toub's [AsyncAutoResetEvent](https://blogs.msdn.microsoft.com/pfxteam/2012/02/11/building-async-coordination-primitives-part-2-asyncautoresetevent/).
 
 Like other "events", an `AsyncAutoResetEvent` is either **set** or **unset** at any time. An `AsyncAutoResetEvent` can be changed from **unset** to **set** by calling its `Set` method. When a `WaitAsync` operation completes, the `AsyncAutoResetEvent` is automatically changed back to the **unset** state.
 
-Moving an `AsyncAutoResetEvent` to the **set** state can only satisfy a single waiter. If there are multiple waiters when `Set` is called, only one will be released. (If this is not the behavior you want, use [[AsyncManualResetEvent]] instead).
+Moving an `AsyncAutoResetEvent` to the **set** state can only satisfy a single waiter. If there are multiple waiters when `Set` is called, only one will be released. (If this is not the behavior you want, use [AsyncManualResetEvent](AsyncManualResetEvent.md) instead).
 
-When an `AsyncAutoResetEvent` is in the **set** state (with no waiters), `Set` is a noop. The `AsyncAutoResetEvent` will not remember how many times `Set` is called; those extra signals are "lost". (If this is not the behavior you want, use [[AsyncSemaphore]] instead).
+When an `AsyncAutoResetEvent` is in the **set** state (with no waiters), `Set` is a noop. The `AsyncAutoResetEvent` will not remember how many times `Set` is called; those extra signals are "lost". (If this is not the behavior you want, use [AsyncSemaphore](AsyncSemaphore.md) instead).
 
 The task returned from `WaitAsync` will enter the `Completed` state when the wait is satisfied and the `AsyncAutoResetEvent` has been automatically reset. That same task will enter the `Canceled` state if the `CancellationToken` is signaled before the wait is satisfied; in that case, the `AsyncAutoResetEvent` has not been automatically reset.
 
 ## Advanced Usage
 
-You can call `WaitAsync` with an [already-cancelled `CancellationToken`](Cancellation) to attempt to acquire the `AsyncAutoResetEvent` immediately without actually entering the wait queue.
+You can call `WaitAsync` with an [already-cancelled `CancellationToken`](Cancellation.md) to attempt to acquire the `AsyncAutoResetEvent` immediately without actually entering the wait queue.

doc/AsyncCollection.md

@@ -1,5 +1,5 @@
 ## Overview
 
-An `AsyncCollection` is an `async`-compatible wrapper around [[IProducerConsumerCollection|https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.iproducerconsumercollection-1]] collections such as [[ConcurrentQueue|https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentqueue-1]] or [[ConcurrentBag|https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentbag-1]].
+An `AsyncCollection` is an `async`-compatible wrapper around [IProducerConsumerCollection](https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.iproducerconsumercollection-1) collections such as [ConcurrentQueue](https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentqueue-1) or [ConcurrentBag](https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentbag-1).
 
-This makes `AsyncCollection` an `async` near-equivalent of [[BlockingCollection|https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.blockingcollection-1]], which is a blocking wrapper around [[IProducerConsumerCollection|https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.iproducerconsumercollection-1]].
+This makes `AsyncCollection` an `async` near-equivalent of [BlockingCollection](https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.blockingcollection-1), which is a blocking wrapper around [IProducerConsumerCollection](https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.iproducerconsumercollection-1).

doc/AsyncConditionVariable.md

@@ -1,8 +1,8 @@
 ## Overview
 
-This is an `async`-ready [[condition variable|http://en.wikipedia.org/wiki/Condition_variable]], a classical synchronization primitive in computer science without a direct .NET equivalent.
+This is an `async`-ready [condition variable](https://en.wikipedia.org/wiki/Condition_variable), a classical synchronization primitive in computer science without a direct .NET equivalent.
 
-An `AsyncConditionVariable` is associated with a single [[AsyncLock]]. All methods on the `AsyncConditionVariable` type ***require*** that you hold the associated lock before calling them. There's no runtime checks for these preconditions because there is no way to check them; you'll just have to be careful. I recommend you combine the `AsyncLock` with its associated `AsyncConditionVariable` instances into a higher-level custom lock/signal system. Note that the simple case of a single `AsyncLock` with a single `AsyncConditionVariable` is equivalent to [[AsyncMonitor]].
+An `AsyncConditionVariable` is associated with a single [AsyncLock](AsyncLock.md). All methods on the `AsyncConditionVariable` type ***require*** that you hold the associated lock before calling them. There's no runtime checks for these preconditions because there is no way to check them; you'll just have to be careful. I recommend you combine the `AsyncLock` with its associated `AsyncConditionVariable` instances into a higher-level custom lock/signal system. Note that the simple case of a single `AsyncLock` with a single `AsyncConditionVariable` is equivalent to [AsyncMonitor](AsyncMonitor.md).
 
 Waiting on an `AsyncConditionVariable` enables an `async` method to (asynchronously) wait for some condition to become true. While waiting, that `async` method gives up the `AsyncLock`. When the condition becomes true, another `async` method notifies the `AsyncConditionVariable`, which re-acquires the `AsyncLock` and releases the waiter.
 

doc/AsyncCountdownEvent.md

@@ -1,6 +1,6 @@
 ## Overview
 
-This is the `async`-ready almost-equivalent of [[CountdownEvent|https://docs.microsoft.com/en-us/dotnet/api/system.threading.countdownevent]], similar to Stephen Toub's [[AsyncCountdownEvent|https://blogs.msdn.microsoft.com/pfxteam/2012/02/11/building-async-coordination-primitives-part-3-asynccountdownevent/]]. It's only an *almost* equivalent because the `AsyncCountdownEvent` does not allow itself to be reset.
+This is the `async`-ready almost-equivalent of [CountdownEvent](https://docs.microsoft.com/en-us/dotnet/api/system.threading.countdownevent), similar to Stephen Toub's [AsyncCountdownEvent](https://blogs.msdn.microsoft.com/pfxteam/2012/02/11/building-async-coordination-primitives-part-3-asynccountdownevent/). It's only an *almost* equivalent because the `AsyncCountdownEvent` does not allow itself to be reset.
 
 An `AsyncCountdownEvent` starts out **unset** and becomes **set** only once, when its **count** reaches zero. Its current count can be manipulated by any other tasks up until the time it reaches zero. When the count reaches zero, all waiting tasks are released.
 

doc/AsyncLazy.md

@@ -1,5 +1,5 @@
 ## Overview
 
-The `AsyncLazy<T>` type enables [[asynchronous lazy initialization|https://blog.stephencleary.com/2012/08/asynchronous-lazy-initialization.html]], similar to [[Stephen Toub's AsyncLazy|https://blogs.msdn.microsoft.com/pfxteam/2011/01/15/asynclazyt/]].
+The `AsyncLazy<T>` type enables [asynchronous lazy initialization](https://blog.stephencleary.com/2012/08/asynchronous-lazy-initialization.html), similar to [Stephen Toub's AsyncLazy](https://blogs.msdn.microsoft.com/pfxteam/2011/01/15/asynclazyt/).
 
 An `AsyncLazy<T>` instance is constructed with a factory method. When the `AsyncLazy<T>` instance is `await`ed or its `Start` method is called, the factory method starts on a thread pool thread. The factory method is only executed once. Once the factory method has completed, all future `await`s on that instance complete immediately.

doc/AsyncLock.md

@@ -1,6 +1,6 @@
 ## Overview
 
-This is the `async`-ready almost-equivalent of the `lock` keyword or the [[Mutex type|https://docs.microsoft.com/en-us/dotnet/api/system.threading.mutex]], similar to Stephen Toub's [[AsyncLock|https://blogs.msdn.microsoft.com/pfxteam/2012/02/12/building-async-coordination-primitives-part-6-asynclock/]]. It's only _almost_ equivalent because the `lock` keyword permits reentrancy, which is not currently possible to do with an `async`-ready lock.
+This is the `async`-ready almost-equivalent of the `lock` keyword or the [`Mutex` type](https://docs.microsoft.com/en-us/dotnet/api/system.threading.mutex), similar to Stephen Toub's [AsyncLock](https://blogs.msdn.microsoft.com/pfxteam/2012/02/12/building-async-coordination-primitives-part-6-asynclock/). It's only _almost_ equivalent because the `lock` keyword permits reentrancy, which is not currently possible to do with an `async`-ready lock.
 
 An `AsyncLock` is either taken or not. The lock can be asynchronously acquired by calling `LockAsync`, and it is released by disposing the result of that task. `AsyncLock` taken an optional `CancellationToken`, which can be used to cancel the acquiring of the lock.
 
@@ -40,7 +40,7 @@ public async Task DoStuffAsync()
 
 `AsyncLock` also supports synchronous locking with the `Lock` method.
 
-You can call `Lock` or `LockAsync` [with an already-cancelled `CancellationToken`](Cancellation) to attempt to acquire the `AsyncLock` immediately without actually entering the wait queue.
+You can call `Lock` or `LockAsync` [with an already-cancelled `CancellationToken`](Cancellation.md) to attempt to acquire the `AsyncLock` immediately without actually entering the wait queue.
 
 ## Really Advanced Usage
 

doc/AsyncManualResetEvent.md

@@ -1,6 +1,6 @@
 ## Overview
 
-This is the `async`-ready equivalent of [[ManualResetEvent|https://docs.microsoft.com/en-us/dotnet/api/system.threading.manualresetevent]], similar to Stephen Toub's [[AsyncManualResetEvent|https://blogs.msdn.microsoft.com/pfxteam/2012/02/11/building-async-coordination-primitives-part-1-asyncmanualresetevent/]].
+This is the `async`-ready equivalent of [ManualResetEvent](https://docs.microsoft.com/en-us/dotnet/api/system.threading.manualresetevent), similar to Stephen Toub's [AsyncManualResetEvent](https://blogs.msdn.microsoft.com/pfxteam/2012/02/11/building-async-coordination-primitives-part-1-asyncmanualresetevent/).
 
 Like other "events", an `AsyncManualResetEvent` is either **set** or **unset** at any time. An `AsyncManualResetEvent` can be changed from **unset** to **set** by calling its `Set` method, and it can be changed from **set** to **unset** by calling its `Reset` method.
 
@@ -12,4 +12,4 @@ The task returned from `WaitAsync` will enter the `Completed` state when the `As
 
 `AsyncManualResetEvent` also supports synchronous waiting with the `Wait` method.
 
-You can call `Wait` with an [already-cancelled `CancellationToken`](Cancellation) to test whether the `AsyncManualResetEvent` is in the **set** state.
+You can call `Wait` with an [already-cancelled `CancellationToken`](Cancellation.md) to test whether the `AsyncManualResetEvent` is in the **set** state.

doc/AsyncMonitor.md

@@ -1,8 +1,8 @@
 ## Overview
 
-This is the `async`-ready almost-equivalent of [[Monitor|https://docs.microsoft.com/en-us/dotnet/api/system.threading.monitor]]. It's only _almost_ equivalent because the `Monitor` type permits reentrancy, which is not currently possible to do with an `async`-ready lock.
+This is the `async`-ready almost-equivalent of [Monitor](https://docs.microsoft.com/en-us/dotnet/api/system.threading.monitor). It's only _almost_ equivalent because the `Monitor` type permits reentrancy, which is not currently possible to do with an `async`-ready lock.
 
-An `AsyncMonitor` is an [[AsyncLock]] with a single associated [[AsyncConditionVariable]]. It is either entered or not. The `AsyncMonitor` can be asynchronously entered by calling `EnterAsync`, and you can leave it by disposing the result of that task.
+An `AsyncMonitor` is an [AsyncLock](AsyncLock.md) with a single associated [AsyncConditionVariable](AsyncConditionVariable.md). It is either entered or not. The `AsyncMonitor` can be asynchronously entered by calling `EnterAsync`, and you can leave it by disposing the result of that task.
 
 While in the monitor, a task may decide to wait for a signal by calling `WaitAsync`. While waiting, it temporarily leaves the monitor until it receives a signal and re-enters the monitor.
 
@@ -18,4 +18,4 @@ Note that the correct logic for waiting on monitor signals is to wait in a loop
 
 ## Advanced Usage
 
-You can call `EnterAsync` with an [already-cancelled `CancellationToken`](Cancellation) to attempt to enter the monitor immediately without actually entering the wait queue.
+You can call `EnterAsync` with an [already-cancelled `CancellationToken`](Cancellation.md) to attempt to enter the monitor immediately without actually entering the wait queue.

doc/AsyncProducerConsumerQueue.md

@@ -1,3 +1,3 @@
 ## Overview
 
-An `AsyncProducerConsumerQueue` is a queue of items that provides `async`-compatible *Enqueue* and *Dequeue* operations. [[AsyncCollection]] is more flexible than this type, but it is also more complex.
+An `AsyncProducerConsumerQueue` is a queue of items that provides `async`-compatible *Enqueue* and *Dequeue* operations. [AsyncCollection](AsyncCollection.md) is more flexible than this type, but it is also more complex.

doc/AsyncReaderWriterLock.md

@@ -1,6 +1,6 @@
 ## Overview
 
-This is the `async`-ready almost-equivalent of the the [[ReaderWriterLockSlim type|https://docs.microsoft.com/en-us/dotnet/api/system.threading.readerwriterlockslim]], similar to Stephen Toub's [[AsyncReaderWriterLock|https://blogs.msdn.microsoft.com/pfxteam/2012/02/12/building-async-coordination-primitives-part-7-asyncreaderwriterlock/]]. It's only _almost_ equivalent because the `ReaderWriterLockSlim` can be constructed in a way which allows reentrancy, and this is not currently possible to do with an `async`-ready lock.
+This is the `async`-ready almost-equivalent of the the [ReaderWriterLockSlim type](https://docs.microsoft.com/en-us/dotnet/api/system.threading.readerwriterlockslim), similar to Stephen Toub's [AsyncReaderWriterLock](https://blogs.msdn.microsoft.com/pfxteam/2012/02/12/building-async-coordination-primitives-part-7-asyncreaderwriterlock/). It's only _almost_ equivalent because the `ReaderWriterLockSlim` supports upgradeable locks and can be constructed in a way which allows reentrancy, and this is not currently possible to do with an `async`-ready lock.
 
 There are two types of locks that can be taken on an `AsyncReaderWriterLock`:
 * Write locks, which are fully exclusive. They do not allow other locks of any kind.
@@ -12,4 +12,4 @@ The tasks returned from `WriterLockAsync` and `ReaderLockAsync` will enter the `
 
 ## Advanced Usage
 
-You can call `WriterLockAsync` and `ReaderLockAsync` with an [already-cancelled `CancellationToken`](Cancellation) to attempt to acquire the `AsyncReaderWriterLock` immediately without actually entering the wait queue.
+You can call `WriterLockAsync` and `ReaderLockAsync` with an [already-cancelled `CancellationToken`](Cancellation.md) to attempt to acquire the `AsyncReaderWriterLock` immediately without actually entering the wait queue.