Added a basic example

xml/System.Threading.Tasks/Task.xml

@@ -5445,11 +5445,46 @@ Task t Status: RanToCompletion, Result: 42
           <format type="text/markdown"><![CDATA[  
 
 ## Remarks  
- You can use `await Task.Yield();` in an asynchronous method to force the method to complete asynchronously. If there is a current synchronization context (<xref:System.Threading.SynchronizationContext> object), this will post the remainder of the method's execution back to that context. However, the context will decide how to prioritize this work relative to other work that may be pending. The synchronization context that is present on a UI thread in most UI environments will often prioritize work posted to the context higher than input and rendering work. For this reason, do not rely on `await Task.Yield();` to keep a UI responsive.  For more information, see the entry [Useful Abstractions Enabled with ContinueWith](https://devblogs.microsoft.com/pfxteam/useful-abstractions-enabled-with-continuewith/) in the Parallel Programming with .NET blog.  
+You can use `await Task.Yield();` in an asynchronous method to force the method to complete asynchronously. If there is a current synchronization context (<xref:System.Threading.SynchronizationContext> object), this will post the remainder of the method's execution back to that context. However, the context will decide how to prioritize this work relative to other work that may be pending. The synchronization context that is present on a UI thread in most UI environments will often prioritize work posted to the context higher than input and rendering work. For this reason, do not rely on `await Task.Yield();` to keep a UI responsive.  For more information, see the entry [Useful Abstractions Enabled with ContinueWith](https://blogs.msdn.com/b/pfxteam/archive/2008/07/23/8768673.aspx) in the Parallel Programming with .NET blog.
+
+`Task.Yield` is used in wrong scenarios very often and that's to try to “refresh” the UI:
+
+```cs
+// Bad code, do not use!!
+async Task LongRunningCpuBoundWorkAsync()
+{
+  // This method is called directly from the UI, and
+  //  does lots of CPU-bound work.
+  // Since this blocks the UI, this method is given
+  //  an async signature and periodically "yields".
+  for (int i = 0; i != 1000000; ++i)
+  {
+    ... // CPU-bound work.
+    await Task.Yield();
+  }
+}
+```
+
+However, this approach will not work. The reason is that UI message loops are priority queues, and any scheduled continuations have a much higher priority than “repaint the window”. So, the `Yield` schedules the continuation and returns to the message loop, and the message loop immediately executes that continuation without processing any of its `WM_PAINT` messages.
+
+A very good usecase of `Task.Yield` is in unit tests when you need to ensure that a particular method would in fact work if its asynchronous operation did not complete synchronously, or to ensure that the code under test is exercised when it receives a `Task` that's not complete:
+
+```cs
+// In a fake service:
+public async Task<int> CountOrderFromDb)
+{
+   // simulate async operation reading a database
+   // but use yield, not Task.Delay so it doesn't slow down text execution.
+   await Task.Yield();
+   return 5;
+}
+```
+
+In conclusion, `Task.Yield` is occasionally useful when unit testing, but much less so for production code.
 
  ]]></format>
         </remarks>
       </Docs>
     </Member>
   </Members>
-</Type>
+</Type>