环形缓冲区与镜像内存（下）

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2012-02-17-ring-buffers-and-mirrored-memory-part-ii.html

Last time on Friday Q&A, I started talking about implementing a ring buffer using virtual memory tricks to mirror memory. The first article concentrated on those virtual memory tricks. Today, I’m going to fill out the second half of the puzzle and show how to implement the ring buffer on top of the mirrored memory allocator we developed. If you haven’t read the previous article yet, I strongly recommend you so so, otherwise the memory mirroring is likely to be confusing.

CodeJust like last time, the code we’re going to discuss is available on GitHub:

https://github.com/mikeash/MAMirroredQueue

GoalsThe mirrored memory trick allows exposing pointers to the interior buffer to the outside world, since both data and free space are always contiguous. The goal then is to create an API which makes this easy to use. In default operation, the ring buffer should also grow to accommodate newly written data. For multithreaded use, the ring buffer’s size can be locked, at which point the buffer becomes thread safe for one simultaneous reader and writer. For that case, thread safety should be acheived with no locks.

APIThe ring buffer is implemented in a class called MAMirroredQueue:

1
    @interface MAMirroredQueue : NSObject

For reading, there are three methods. One method retrieves how much data is available to be read, one method returns a pointer to the data, and one method advances the pointer:

1
    - (size_t)availableBytes;
2
    - (void *)readPointer;
3
    - (void)advanceReadPointer: (size_t)howmuch;

This way a client can find out how much data it can read, it can access the data, and then when it’s finished it can remove that data from the ring buffer by advancing the pointer.

For writing data, the interface is similar. However, instead of a method to query the amount of data, there’s a method to simply ensure that the necessary amount of free space is available:

1
    - (BOOL)ensureWriteSpace: (size_t)howmuch;
2
    - (void *)writePointer;
3
    - (void)advanceWritePointer: (size_t)howmuch;

The ensureWriteSpace: method returns success or failure. When allocation is not locked (the default state), it will always succeed. When allocation is locked (to ensure thread safety), it will succeed only if there is enough free space in the buffer, and return NO otherwise.

The other two methods in write API are the same as in the read API: one to retrieve the data pointer, and one to advance it once data is written.

With all this talk of locking allocations, we probably want some methods to actually manage that:

1
    - (void)lockAllocation;
2
    - (void)unlockAllocation;

The queue starts out unlocked. If thread-safe operation is needed, the desired amount of space can be allocated by calling ensureWriteSpace:, and afterwards lockAllocation ensures that the buffer doesn’t get reallocated. If the buffer ever needs to be expanded in the future, unlockAllocation followed by another ensureWriteSpace: can be used to accomplish that.

Finally, I also wrote a pair of UNIX-like wrappers around the above functionality:

1
    - (size_t)read: (void *)buf count: (size_t)howmuch;
2
    - (size_t)write: (const void *)buf count: (size_t)howmuch;

These aren’t necessary, and are actually inefficient because the API requires copying data into and out of the ring buffer, but an API that shares the semantics of the POSIX read and write calls can be nice to have.

Instance VariablesThe buffer itself is described by three instance variables:

1
    char *_buf;
2
    size_t _bufSize;
3
    BOOL _allocationLocked;

All of which are, I hope, self explanatory. Note that _buf is a char * to allow for easy pointer arithmetic, which will come in handy later. Although gcc and clang allow it, technically pointer arithmetic is not allowed on void * pointers, so char * is a convenient choice for byte-addressed entities.

In addition to the buffer, we also need a read pointer and a write pointer:

1
    char *_readPointer;
2
    char *_writePointer;

Utility FunctionsPage size is important for this code, and it needs to be able to round numbers up and down to a multiple of the page size. I wrote two simple wrappers around mach macros which manage this:

1
    static size_t RoundUpToPageSize(size_t n)
2
    {
3
        return round_page(n);
4
    }
5

6
    static void *RoundDownToPageSize(void *ptr)
7
    {
8
        return (void *)trunc_page((intptr_t)ptr);
9
    }

The first one simply rounds a byte size up to the nearest multiple of page size, and the second one rounds a pointer down to the nearest page boundary.

CodeFirst up is the dealloc method. I’m assuming ARC, so no need to call super. All it does is free the buffer if it’s been allocated:

1
    - (void)dealloc
2
    {
3
        if(_buf)
4
            free_mirrored(_buf, _bufSize, MIRROR_COUNT);
5
    }

MIRROR_COUNT is simply a #define which describes how many mirrored copies to allocate. Interestingly, it’s set to 3, not 2 as you might expect, which is why my mirrored allocator supports an arbitrary number of mirrorings instead of just hardcoding two of them. More on the reasoning for this later.

There is no initializer method, as simply having all of the instance variables set to 0 or NULL is sufficient. The ring buffer starts out empty, and all zeroes describes that just fine.

Next up, we have the availableBytes method. The first thing it does is subtract the read pointer from the write pointer:

1
    - (size_t)availableBytes
2
    {
3
        ptrdiff_t amount = _writePointer - _readPointer;

Normally, this would just be the number of data bytes in the buffer. However, in the event that another thread is modifying this buffer while we’re computing this value, the pointers could be moving around. If they’re just moving around by a read or write amount, then that’s no problem. We may end up computing the old value or the new value for the number of available bytes, but either one works fine.

However, the pointers can also be moved around by the size of the buffer. When the read pointer goes into the second mirrored region, it gets reset back into the first one, and the write pointer follows. Because of this, the computed size here may be less than zero (if we see the update to the write pointer but not the read pointer), or may be greater than the buffer size (if we see the read pointer update but not the write pointer). Since we know that the number of available bytes must be between zero and the buffer size, this is easy to correct: just check for these cases, and adjust the amount accordingly:

1
        if(amount < 0)
2
            amount += _bufSize;
3
        else if((size_t)amount > _bufSize)
4
            amount -= _bufSize;
5

6
        return amount;
7
    }

Next up, we have readPointer. This simply returns the ivar:

1
    - (void *)readPointer
2
    {
3
        return _readPointer;
4
    }

Next, advanceReadPointer:. This simply adds the amount to the read pointer:

1
    - (void)advanceReadPointer: (size_t)howmuch
2
    {
3
        _readPointer += howmuch;

However, it’s not done here. In the event that this advanced the read pointer past the end of the first mirrored region, both it and the write pointer need to be pulled back. For the read pointer, this is simply a matter of subtracting _bufSize. Since the write pointer can be modified by both the reader thread (with this method) and the writer thread (in advanceWritePointer:) simultaneously, it needs to be updated using an atomic operation. I use the built-in __sync_sub_and_fetch function to do this:

1
        if((size_t)(_readPointer - _buf) >= _bufSize)
2
        {
3
            _readPointer -= _bufSize;
4
            __sync_sub_and_fetch(&_writePointer, _bufSize);
5
        }
6
    }

Next comes ensureWriteSpace:. The first part of this is trivial: find out how much free space is available, by subtracting [self availableBytes] from the total buffer size, and if the requested amount is less, everything is all set:

1
    - (BOOL)ensureWriteSpace: (size_t)howmuch
2
    {
3
        size_t contentLength = [self availableBytes];
4
        if(howmuch <= _bufSize - contentLength)
5
            return YES;

Otherwise, we know that the free space is not sufficient to meet the request. If allocation is locked, that’s it, game over, return NO:

1
        else if(_allocationLocked)
2
            return NO;

If allocation is not locked, then it’s time to reallocate the buffer.

The first thing to do is figure out how much memory to allocate, then allocate a new buffer of that size. Recall that, because the mirrored allocator uses virtual memory tricks, it must allocate a multiple of the page size. We need at least contentLength + howmuch memory, so the new buffer size is found by rounding that number up to the nearest page size:

1
        size_t newBufferLength = RoundUpToPageSize(contentLength + howmuch);

Next, allocate the new buffer:

1
        char *newBuf = allocate_mirrored(newBufferLength, MIRROR_COUNT);

Now that we have the new buffer, the code branches a bit. If there’s already an existing buffer, then we’re reallocating memory, and have to copy the data out of the old buffer and into the new:

1
        if(_bufSize > 0)
2
        {

Once again, we’re going to play virtual memory games. Mach provides a vm_copy function which copies page-aligned memory without actually copying it. Instead, the pages are remapped and set up to copy on write. For this case, where we’re going to immediately deallocate the old memory, this means that no data is ever actually copied, and the system just plays some virtual memory tricks to make it look like it was.

We want to copy starting from the read pointer, but because everything has to be page-aligned, the copy has to start at the beginning of the page containing the read pointer:

1
            char *copyStart = RoundDownToPageSize(_readPointer);

Likewise, the length needs to be a multiple of the page size. Starting from copyStart, we need to copy _writePointer - copyStart bytes, but this needs to be rounded up fit the page size:

1
            size_t copyLength = RoundUpToPageSize(_writePointer - copyStart);

Now that this is set, we can “copy” this data into the new buffer:

1
            vm_copy(mach_task_self(), (vm_address_t)copyStart, copyLength, (vm_address_t)newBuf);

Now that the data is copied, we need to compute the location of the new read pointer. We copied additional bytes by rounding _readPointer down to copyStart. The new read pointer is equal to newBuf plus that number of additional bytes:

1
            char *newReadPointer = newBuf + (_readPointer - copyStart);

This spot was particularly troublesome for me when I was developing the code, so I tossed in an assert to make sure that it failed early and loudly:

1
            if(*newReadPointer != *_readPointer)
2
                abort();

Now we can free the old buffer and reassign the read pointer:

1
            free_mirrored(_buf, _bufSize, MIRROR_COUNT);
2
            _readPointer = newReadPointer;

The write pointer is set to equal the read pointer plus the previously computed content length:

1
            _writePointer = _readPointer + contentLength;
2
        }

For the case where no previous buffer exists, the code is simple: just set the read and write pointer to the beginning of the new buffer:

1
        else
2
        {
3
            _readPointer = newBuf;
4
            _writePointer = newBuf;
5
        }

The new buffer is allocated, data is copied if necessary, and now all that remains is to set the _buf and _bufSize ivars and then return YES to the caller:

1
        _buf = newBuf;
2
        _bufSize = newBufferLength;
3

4
        return YES;
5
    }

Next up, the writePointer method, which is once again just a simple accessor:

1
    - (void *)writePointer
2
    {
3
        return _writePointer;
4
    }

The advanceWritePointer: method is also simple, performing an atomic add of _writePointer:

1
    - (void)advanceWritePointer: (size_t)howmuch
2
    {
3
        __sync_add_and_fetch(&_writePointer, howmuch);
4
    }

Note that, unlike advanceReadPointer:, this method doesn’t need any checks to wrap pointers back to the first mirrored data section. The advanceReadPointer: method handles wrapping both read and write pointers. Since no wrapping occurs here, the write pointer can often sit in the second mirrored data section for long periods of time, but that’s perfectly fine.

By having the write pointer always be ahead of the read pointer, this code avoids an annoying ambiguity. A ring buffer which uses read and write pointers usually suffers from a problem when the read and write pointers are equal. There’s no simple way to distinguish between the buffer being empty (where both pointers are equal because there is no data between them) and the buffer being full (where the pointers are equal becaus there’s no free space between them).

Ring buffer implementations typically avoid this either by prohibiting the buffer from becoming completely full, and instead defining “full” as being one unit less than true full capacity, or by using a pointer plus a count rather than using two pointers.

Neither alternative is attractive in this case. Having the buffer be artifically one byte small is particularly painful when playing crazy virtual memory games, since it’s likely that code using this ring buffer will want to deal in whole pages as well, and by losing a single byte out of the buffer, it essentially loses an entire 4kB page. Using a pointer and a count makes achieving lockless thread safety much more difficult if not completely impossible, since the write pointer becomes a derived value computed from two other values, both of which get modified by the read thread, and which can be momentarily inconsistent with each other as seen from another thread when both are updated simultaneously.

The virtual memory games played with mirrored allocation give a third, better way: simply use two pointers, and express “full” by having the write pointer equal the read pointer plus the buffer size. It’s natural, it works great due to the mirrored allocation, and it’s easy to deal with.

Next up are the allocation locking methods. These simply manipulate the _allocationLocked ivar. Nothing else needs to be done in these methods, since they just modify the behavior of ensureWriteSpace:. Here’s the code:

1
    - (void)lockAllocation
2
    {
3
        _allocationLocked = YES;
4
    }
5

6
    - (void)unlockAllocation
7
    {
8
        _allocationLocked = NO;
9
    }

Next, we have the UNIX-like compatibility wrappers. These help illustrate how the more primitive, direct API is used. The read:count: method figures out how much to read using availableBytes, copies data out from readPointer, then calls advanceReadPointer: to mark the data as read:

1
    - (size_t)read: (void *)buf count: (size_t)howmuch
2
    {
3
        size_t toRead = MIN(howmuch, [self availableBytes]);
4
        memcpy(buf, [self readPointer], toRead);
5
        [self advanceReadPointer: toRead];
6
        return toRead;
7
    }

The story for write:count: is a little more complex, as it behaves differently depending on whether allocation is locked. If allocation is locked, then it only writes as much data as will fit in the buffer’s remaining space. Otherwise, it uses ensureWriteSpace: to grow the buffer to the appropriate size, if needed:

1
    - (size_t)write: (const void *)buf count: (size_t)howmuch
2
    {
3
        if(_allocationLocked)
4
            howmuch = MIN(howmuch, _bufSize - [self availableBytes]);
5
        else
6
            [self ensureWriteSpace: howmuch];

The rest is straightforward. It copies the data into writePointer, advances the write pointer, and returns the amount of data written:

1
        memcpy([self writePointer], buf, howmuch);
2
        [self advanceWritePointer: howmuch];
3
        return howmuch;
4
    }

And that completes the implementation of the mirrored queue.

Thread SafetyOne of the goals of this implementation is to be thread safe, for the case where there is one reader thread and one writer thread. The above code achieves this, but it’s not entirely clear why it’s safe. There are no locks, and the read pointer doesn’t even use atomic operations to update.

First, note that the code is only thread safe for the case when allocation is locked. That means that all of the tricky reallocation code in ensureWriteSpace: doesn’t come into play. This is good, because it would be incredibly difficult to make that code thread safe without locking. Given that, we can consider _buf and _bufSize to be constant. The only variables which could be potentially modified by one thread while simultaneouly being read by another thread are _readPointer and _writePointer.

It’s easiest to consider this as two separate cases. First, the reader thread needs to be correct even when the writer thread is modifying these values. Second, the writer thread needs to be correct even when the reader thread is modifying these values. If both hold, then the entire hting is correct.

Let’s look at the first case, of making sure the reader thread is correct in the face of modifications from the writer thread. The writer thread only ever modifies _writePointer. The only place where the reader thread depends on the value of _writePointer is in availableBytes:

1
    ptrdiff_t amount = _writePointer - _readPointer;

This unsynchronized access is perfectly safe. There’s a race condition in that it’s not certain whether the read thread will see the old or new value of _writePointer. However, it doesn’t matter. _writePointer can only increase, and the number of available bytes can likewise only increase. If it sees the old value, it still computes a number of available bytes that’s correct, just slightly out of date. If it sees the new value, then so much the better. Therefore, the reader is safe.

Let’s look at the writer’s safety in the face of changes from the reader now. The reader can alter both pointers, so the analysis is a little more complex. The writer code also calls availableBytes, a method nominally on the reader side, so that method has to be safe for both.

The only way that the reader thread can alter _writePointer is with this line:

1
    __sync_sub_and_fetch(&_writePointer, _bufSize);

Because of the mirrored structure of the underlying buffer, both the old and new values of _writePointer are correct here. availableBytes can deal with either value, and will return the right answer in either case. Likewise, when writePointer returns the value, it doesn’t matter whether it’s the old or new value, as they are both equivalent in terms of what happens when data is written to them. Finally, advanceWritePointer: is safe, since it also uses a __sync builtin to modify _writePointer, ensuring that both updates will be applied in some order, and the particular order is not important.

The only place where the writer thread uses _readPointer is in availableBytes. Just like the corresponding case when the writer thread modifies its pointer and the reader calls availableBytes, it’s safe for the reader thread to modify _readPointer while the writer is calculating availableBytes. Advancing the read pointer decreases the number of available bytes, which increases the amount of write space. If the writer thread sees the old value for _readPointer here, it computes the older, smaller amount of write space, which is still safe, just slightly stale.

The writer thread is safe in the face of changes from the reader thread, and vice versa. Therefore, this code really is thread safe.

TriplicateI promised that I would explain why MAMirroredQueue allocates three mirrored copies of its buffer, and now is the time.

Normally, two copies is enough for the contiguous ring buffer. However, remember that this implementation is a little odd, even for a mirrored ring buffer, in using separate read and write pointers and allowing the write pointer to sit in the second mirrored area. This enables lockless thread safety and use of the full buffer without the strange ambiguity when the two pointers are equal. However, it also requires the existence of a third mirrored area.

The need is extremely rare, but it can happen. To start with, we need a buffer where the data portion has wrapped around to the beginning. In a normal ring buffer, that would look like this:

1
         read
2
          |
3
          v
4
    +----------+
5
    |xxx  xxxxx|
6
    +----------+
7
        ^
8
        |
9
       write

In the mirrored ring buffer, it instead looks like this:

1
         read
2
          |
3
          v
4
    +----------+----------+
5
    |xxx  xxxxx|xxx  xxxxx|
6
    +----------+----------+
7
                   ^
8
                   |
9
                  write

So far so good, still. The write pointer is valid, and writing data into the empty area is correct. Now, let’s say there are separate reader and writer threads manipulating this buffer simultaneously. The reader thread moves the read pointer up:

1
                 read
2
                  |
3
                  v
4
    +----------+----------+
5
    |  x       |  x       |
6
    +----------+----------+
7
                   ^
8
                   |
9
                  write

The next step for the reader thread is to move both read and write pointers down into the first mirrored area. But! Before that can happen, let’s say that the writer suddenly goes to write a bunch of data. (Remember, in the world of preemptive threading, the two threads can run in all sorts of weird orders.) Before the read thread can move any pointers around, the write thread computes the available space, writes data into the buffer, and crashes:

1
                 read
2
                  |
3
                  v
4
    +----------+----------+
5
    |  x       |  xXXXXXXX|XX
6
    +----------+----------+
7
                   ^
8
                   |
9
                  write

The writer wrote off the end of the second mirrored segment! It saw a large amount of free space available, which is correct, but the trouble is that the end of this free space can only be accessed from a write pointer residing in the first mirrored segment. Since we allow the write pointer to hang out in the second mirrored segment, there’s the possibility for trouble. This is a brief race window requiring very specific circumstances to trigger, but it can happen, and it needs to be protected against.

Fortunately, this problem is easy to solve by simply allocating a third mirrored segment. In that case, the sequence looks like this:

1
         read
2
          |
3
          v
4
    +----------+----------+----------+
5
    |xxx  xxxxx|xxx  xxxxx|xxx  xxxxx|
6
    +----------+----------+----------+
7
                   ^
8
                   |
9
                  write
10

11
                 read
12
                  |
13
                  v
14
    +----------+----------+----------+
15
    |  x       |  x       |  x       |
16
    +----------+----------+----------+
17
                   ^
18
                   |
19
                  write
20

21
                 read
22
                  |
23
                  v
24
    +----------+----------+----------+
25
    |XXxXXXXXXX|XXxXXXXXXX|XXxXXXXXXX|
26
    +----------+----------+----------+
27
                   ^
28
                   |
29
                  write

With the extra mirrored region at the end, the surplus data is written to a safe spot and everything works correctly. At this point, the read thread will jump in, shift the pointers down, and life continues as usual.

ConclusionThat wraps up our exploration of a mirrored-memory ring buffer. I hope the journey was enlightening. Oh, and the source code is all available under a standard BSD license in case you have a use for it in your own apps.

Come back next time for another exciting episode. Friday Q&A is, as always, driven by reader input, so send in your ideas for topics in the meantime.