Re: Circular buffer


>If the writer is consistently faster than the reader, and the writer
> is blocked when the queue is full, the writer is forced to synchronize
> its speed with the reader. The result is no different than having a
> single element buffer instead of a queue. If the reader is
> consistently faster than the writer, the reader will block until the
> writer serves the queue. The reader is forced to synchronize with the
> writer, resulting in the same performance as is found with a single
> element buffer.
>
> The designer of the system now has two options: ensure every queue
> element
> is read before it is over-written (and read only once), or allow the
> writer to over-write unread messages and the reader to read
> already-read
> messages. If the first choice is taken, then a single element buffer
> will
> produce almost exactly the same performance as a circular queue, with a
> lot less complexity. If the second choice is taken the data in the
> circular queue must be protected from simultaneous reading and writing.

I think i have created some confusions. The circular buffer is self
contained. The system itself is pretty much tight on ensuring the
writer and reader threads are in sync (Using a flow control algorithm
).

Let me elaborate my problem. Say, i am interfacing my system to a
legacy sy
system which provides read access through an API. Where the read API
signature is approximately as shown below.

read(char* startptr, int numberofbytes_to_read, int
*numberofbytes_read);

The implementation of read API would actually start copying data to the
startptr. Here is the catch. I wish to give the startptr as the
"writeptr" of my circular buffer. If the *read* API had used my enque()
function of my circular buffer to copy the contents, i wouldn't have
had to worry at all. My bad, it is not. Instead it is using a memcpy.
My idea, is to start a monitor thread in the implementation of circular
buffer. So whenever the circular buffer is initiated the thread starts
and watches the progress of the writeptr (and possibly readptr) and
make sure that it doesn't collides with readptr and the pointers are
wraped around safely without permitting access to the border locations
of the array. Is this a good idea ?.

.

Relevant Pages

  • Re: [PATCH 3/3] ring-buffer: add design document
    ... +buffer before the consumer could free up anything, ... +but a writer may preempt another writer, ... nor can a reader preempt another reader. ... reads of the ring buffer from an interrupt. ...
    (Linux-Kernel)
  • Re: [PATCH 3/3] ring-buffer: add design document
    ... +buffer before the consumer could free up anything, ... +but a writer may preempt another writer, ... nor can a reader preempt another reader. ... reads of the ring buffer from an interrupt. ...
    (Linux-Kernel)
  • Re: [PATCH 3/3] ring-buffer: add design document
    ... +buffer before the consumer could free up anything, ... +but a writer may preempt another writer, ... nor can a reader preempt another reader. ... commit page - the page that last finished a write. ...
    (Linux-Kernel)
  • [PATCH v2 0/3] [GIT PULL] Lockless Ring Buffer Version 2
    ... This is v2 of the ring buffer design. ... -but a writer may preempt another writer, ... nor can a reader preempt another reader. ...
    (Linux-Kernel)
  • [PATCH 2/3] ring-buffer: make lockless
    ... and read from the head. ... buffer is now just a reference to where to look. ... When the writer wraps the buffer and the tail meets the head, ... the reader on another CPU will not take the ...
    (Linux-Kernel)
Loading