anchor.diff:  - **YieldingWaitStrategy** ->
   
   --
  -The `YieldingWaitStrategy` is one of 2 Wait Strategies that can be use in low latency systems, where there is the option to burn CPU cycles with the goal of improving latency.
  -The `YieldingWaitStrategy` will busy spin waiting for the sequence to increment to the appropriate value.
  -Inside the body of the loop `Thread.yield()` will be called allowing other queued threads to run.
  -This is the recommended wait strategy when need very high performance and the number of Event Handler threads is less than the total number of logical cores, e.g. you have hyper-threading enabled.
  +The `YieldingWaitStrategy` is one of two ``WaitStrategy``s that can be use in low-latency systems.
  +It is designed for cases where there is the option to burn CPU cycles with the goal of improving latency.
  +
  +The `YieldingWaitStrategy` will busy spin, waiting for the sequence to increment to the appropriate value.
  +Inside the body of the loop `Thread#yield()` will be called allowing other queued threads to run.
  +
  +This is the recommended wait strategy when you need very high performance, and the number of `EventHandler` threads is lower than the total number of logical cores, e.g. you have hyper-threading enabled.
   --
   
   - **BusySpinWaitStrategy** ->
   
   --
  -The `BusySpinWaitStrategy` is the highest performing Wait Strategy, but puts the highest constraints on the deployment environment.
  -This wait strategy should only be used if the number of Event Handler threads is smaller than the number of physical cores on the box. E.g. hyper-threading should be disabled.
  +The `BusySpinWaitStrategy` is the highest performing `WaitStrategy`.
  +Like the `YieldingWaitStrategy`, it can be used in low-latency systems, but puts the highest constraints on the deployment environment.
  +
  +This wait strategy should only be used if the number of `EventHandler` threads is lower than the number of physical cores on the box, e.g. hyper-threading should be disabled.
   --
   
   === Clearing Objects From the Ring Buffer
   
   When passing data via the Disruptor, it is possible for objects to live longer than intended.
   To avoid this happening it may be necessary to clear out the event after processing it.
  -If you have a single event handler clearing out the value within the same handler is sufficient.
  +
  +If you have a single event handler, clearing out the value within the same handler is sufficient.
   If you have a chain of event handlers, then you may need a specific handler placed at the end of the chain to handle clearing out the object.
   
   .Example `ObjectEvent`
  
positive.code: === Basic Tuning Options
  
  Using the above approach will work functionally in the widest set of deployment scenarios.
  However, if you able to make certain assumptions about the hardware and software environment that the Disruptor will run in then you can take advantage of a number of tuning options to improve performance.
  There are 2 main options for tuning, single vs. multiple producers and alternative wait strategies.
  
  ==== Single vs. Multiple Producers
  
  One of the best ways to improve performance in concurrent systems is to adhere to the http://mechanical-sympathy.blogspot.co.nz/2011/09/single-writer-principle.html[Single Writer Principle], this applies to the Disruptor.
  If you are in the situation where there will only ever be a single thread producing events into the Disruptor, then you can take advantage of this to gain additional performance.
  
  .Using a single producer
  [source,java]
  ----
  public class LongEventMain
  
negative.code: - replication (sending the input data to another machine to ensure that there is a remote copy of the data);
  - and business logic (the real processing work).
  
  Looking at <<user-guide-models>> is possible to see that there are 3 ``EventHandler``s listening (`JournalConsumer`, `ReplicationConsumer` and `ApplicationConsumer`) to the Disruptor.
  Each of these Event Handlers will receive *all* the messages available in the Disruptor (in the same order).
  This allows for work for each of these consumers to operate in parallel.
  ****
  
  