【数据结构】BipBuffer学习笔记

BipBuffer

原文链接：The Bip Buffer - The Circular Buffer with a Twist

BipBuffer 运行过程与示意图

缓冲区起初为空，没有任何区域（见图 1）。

然后，当数据首次放入缓冲区时，会创建一个单一区域（“A”区域）（见图 2）。（比如说，先叫“保留”，然后叫“提交 ”。）

数据被添加到区域A，向右延伸（见图3）。

这是我们首次从缓冲区中移除数据（见图 4）

这种情况会持续到区域到达缓冲区末端（图 4）。当区域 A 左侧的空闲空间多于右侧时（写入请求的空间大于尾部空间时），该区域内会创造第二个区域（“区域 B”）。选择在左侧空间更多时创建新区域，是为了最大化缓冲区中可用的潜在空闲空间。所有这些结果让我们得到的画面看起来很像图 5。

如果我们现在用掉了更多的缓冲区空间，就会得到图 6，新的空间只从区域 B 的末端分配。如果我们最终分配足够的数据，使得区域 A 和 B 之间所有的空闲空间都被用掉（图 7），缓冲区中就没有可用空间了，只能在读取数据之前进行预留。

如果我们再从缓冲区读取更多数据（比如区域 A 的全部剩余内容），就会完全耗尽。此时，由于区域 A 完全空了，我们就不需要再追踪两个独立区域，区域 B 的所有内部数据都会复制到区域 A 的内部数据上，区域 B 也完全清除。（图 8）

如果我们从缓冲区中读取更多数据，就会得到类似图4的图，循环继续。

通过缓冲区末尾的绕回点分割系统调用的缺点与 BipBuffer 的解决方案

原文如下：

Another possibility which was brought up in the bulletin board (and the person who brought it up shall remain nameless, if just because they... erm... are nameless) was that of just splitting the calls across wraps. Well, this is one way of working around the wrapping problem, but it has the unfortunate side-effect that as your buffer fills, the amount of free space which you pass out to any calls always decreases to 1 byte at the minimum - even if you've got another 128kb of free space at the beginning of your buffer, at the end of it, you're still going to have to deal with ever shrinking block sizes.
直接将调用跨绕回点进行分割。这确实是解决绕回问题的一种方法，但它有一个不幸的副作用：随着缓冲区逐渐被填满，你传递给任何调用的可用空间量最终将减少到至少1字节——即使你的缓冲区开头还有另外128KB的可用空间，但在其末尾，你仍将不得不处理不断缩小的块大小。

这里我个人认为作者同时说了两种传统环形缓冲区的问题，即：

1. 放着缓冲区头部的可能出现的大块空闲空间不用用尾部的小空间，如果头部的大块空闲空间大于本次写入需要的空间，那么使用尾部的空间会多出一次系统调用的开销
2. 当写指针与读指针之间只差 1kb 时，如果写指针写入的同时读指针又释放了 1kb 空间时，那么会陷入到不断的分割写入直到所有的待写入内容写完，性能会急剧恶化（见上图）

前提知识：
系统调用（如 recv, write）是昂贵的：每一次调用都涉及从用户态切换到内核态，上下文切换、参数检查等开销。因此，一次传输1000字节比10次传输100字节要高效得多。

因此，BipBuffer 为了解决这个问题，它要求当 写入所需的空间小于缓冲区尾部空间时，在缓冲区头部创建新区域并将数据放入其中（当然我觉得如果尾部空间足够支持下一次的写入，那么先用尾部空间也未尝不可），这样虽然会降低空间利用率（尾部可能会出现无法利用的空间），但是

1. 规避不断分割调用的极端场景，也比一般场景下的分割调用要更加高效
2. 使用一整块的内存，对于许多 api 来说更加的友好

一种更简单的 BipBuffer

原文链接：Bip Buffer Made Easy