anchor.diff:  
   ===== Writes and reads using ring buffer
   
  -If both `writeBufferMode` and `readBufferMode` are set to `BufferMode.Asynchronous` then any writes to the
  -queue will be given to the ring buffer and reads will read from the ring buffer. This gives the lowest possible
  -latency as the disk subsystem is not involved at all. As with asynchronous writes, a background task is
  -created in the builder's event loop to drain the ring buffer in to the underlying (disk-backed) chronicle queue.
  +If both `writeBufferMode` and `readBufferMode` are set to `BufferMode.Asynchronous` then any writes to the queue will be given to the ring buffer and reads will read from the ring buffer. This gives the lowest possible latency as the disk subsystem is not involved at all. As with asynchronous writes, a background task is created in the builder's event loop to drain the ring buffer in to the underlying (disk-backed) chronicle queue.
   
  -Example for asynchronous reads and writes using a memory-mapped file and two processes
  +====== Example for asynchronous reads and writes using a memory-mapped file and two processes
   
   ```
       // process 1
  
positive.code: 
  === Chronicle Ring Buffer and Chronicle Queue
  
  There are two types of Chronicle Queue which are backed by the ring buffer
  
  ==== software.chronicle.enterprise.queue.RingBufferChronicleQueue
  
  This queue does not implement the full contract of `ChronicleQueue` and will throw `UnsupportedOperationException`
  from some methods. It is created as below where `ringBuffer` is the ring buffer to back this queue with,
  `wireType` is the wireType to use when appending and tailing, `pauser` is the pauser to use by the appender
  when waiting for readers.
  
  ```
      ChronicleQueue rbq = new RingBufferChronicleQueue(ringBuffer, wireType, pauser);
  ```
  
  And can be used in the same way as any other ChronicleQueue implementation.
  
  ==== software.chronicle.enterprise.queue.EnterpriseSingleChronicleQueue
  
  The ring buffer can be used in one of two ways in EnterpriseSingleChronicleQueue, and this is controlled by
  the builder's `readBufferMode` and `writeBufferMode`.
  
  ===== Asynchronous writes
  
  If `writeBufferMode` is set to `BufferMode.Asynchronous` then any writes to the queue will be given to the
  ring buffer and a background task is created in the builder's event loop to drain the ring buffer in to
  the underlying (disk-backed) chronicle queue. Reads are made from the underlying queue. This use case is
  designed to help with very bursty writes, which cannot afford to be blocked by a slow underlying disk
  subsystem. The ring buffer's buffer size must be carefully chosen to allow for the maxmimum burst size.
  
  Example:
  
  ```
      try (ChronicleQueue queue = EnterpriseChronicleQueueBuilder
  
negative.code: = Ring Buffer
  :toc:
  :toc-title: Contents
  :toclevels: 1
  
  == Chronicle Queue Enterprise Ring Buffer
  
  Chronicle Queue Enterprise Ring Buffer provides a high performance, multi-writer, multi-reader, ring buffer implementation which can be used in your application code.
  
  Additionally, it allows the ring buffer to be accessed
  through two different implementations of the `ChronicleQueue` interface.
  
  .Chronicle Ring Buffer
  image::images/Ring_buffer.svg[]
  
  === The mechanics of Chronicle Ring Buffer
  
  The Chronicle Queue Enterprise Ring Buffer is a multi-writer, multi-reader, zero-garbage collection, monitored ring buffer implementation which takes `Bytes`.
  
  As the Chronicle stack is built on `Bytes`, you can use the ring buffer for byte arrays, packed objects, or you can serialise (or de-serialise objects out of, or into, it using
  https://github.com/OpenHFT/Chronicle-Wire[Chronicle Wire].
  
  When you create a ring buffer then any reader can block all writers. If a reader stops reading
  then this will eventually block writers. The number of readers is fixed, and they are all created when the ring buffer is created; when the underlying BytesStore is first written-to. The readers will live for as long as the ring buffer; until you stop using the BytesStore.
  
  Backing the ring buffer with a persistent BytesStore (that is, one backed with a memory-mapped file) means it will be visible to multiple processes. All processes can write to, and read from, the ring buffer.
  
  ==== Common scenarios:
  - Back the ring buffer with an in-memory BytesStore. +
  You can have multiple writers and multiple readers in the same process. The ring buffer does not survive longer than the process.
  
  - Back the ring buffer with a memory-mapped BytesStore. +
  You can have multiple writers and multiple readers in multiple processes. The ring buffer's data can outlast individual processes.
  
  To use the basic ring buffer, you must create it by calling `newInstance`.
  
  NOTE: The number of readers must be specified at creation. If not provided, the number of readers is assumed to be `1`. The `BytesStore` must be an
  implementation of `NativeBytesStore`, and must be sized appropriately by using the `sizeFor` method. The base size must be a power of `2`.
  
  ```
    int size = BytesRingBuffer.sizeFor(2 << 20);
  