在CSDN上有很多关于高耦合存储库的博客,人们认为最好的是Longko的[Project Design]高耦合存储库,它强烈推荐阅读。
这个博客将总结和扩展基于Longgo博客,包括如何修改兼容Windows和Linux操作系统,哪些领域应注意的细节,等等。
项目源代码:C++实现的高耦合存储库项目。源代码的直接复制可以在Windows或Linux上运行。
文章目录
- 实现Linux和Windows跨系统运行
- 一些需要注意的问题
- 延长内存池锁定和大小问题
- 线程末端内存泄漏有问题
实现Linux和Windows跨系统运行
原始项目主要运行在Windows下,如果你想兼容Linux,首先需要将内存接口应用和释放到Linux下的条件编译器:
此外,由于Linux下没有基于Windows的TLS接口,因此有必要将TLS转换为基于Linux的__thread当使用TLS时,可以直接编译条件:
在Linux中,原子定义在初始化时不支持,所以先定义它们,然后分配值。
Linux和Windowsclock()该函数的返回值是与编译器相关的硬件滴答。
在Windows的VS下每1000个滴答是一秒，在Linux的g++下为1000000个滴答为一秒。所以Linux下的返回值是Windows下的一千倍。
如果您想计算多少秒,您需要使用CLOCKS_PER_SEC,用来表示每秒计数多少钟单位,即硬件点数。
为了解决上述问题,你只需要写一个运行程序的makefile:
一些需要注意的问题
延长内存池锁定和大小问题
以前的固定存储池被解锁,所以多个线程适用于一个固定存储池pTLSThreadCache时就会出现问题：
这里有两个解决方案:一个是Longgo,它在应用程序之前被锁定。
另一个是锁定固定内存池,在应用和释放内存时锁定和解锁:
第二个选项在这里更推荐,因为它可以使存储池的长度更安全,减少外部锁定的麻烦。
此外,在确定记忆池的长度时,要小心两点,一个是,obj的大小必须比指针的空间大,否则你不可能形成一个链表;第二个是大块空间不够的时候,我们需要重新打开大量的空间,但是,这个新开的大块空间可能不够 obj 大小(例如,在使用3层基树 64 位时需要打开第一层节点,就会出现这种情况，因为第一层节点需要打开超过1M的空间,但为了避免浪费，我们不会开一个这么大的储存区),所以我们需要作出判断,如果 obj比一个大的空间块大,然后你需要打开一个obj大小空间。
线程末端内存泄漏有问题
虽然我们已经有 ThreadCache 返回内存到 CentralCache 的接口,但还有一个前提,那就是 ThreadCache Hash 桶中链表的长度在返回之前必须达到一定长度。
这意味着当一个线程结束时,即使程序员叫ConcurrentFree恢复内存,它只能恢复到ThreadCache,而ThreadCache不一定恢复到CentralCache。
因此, ThreadCache 中存在了一个存储器泄漏问题。
这里有许多解决方案,其中最简单的是手写一个接口返回 ThreadCache内存,基本上是相同的ReleaseListToSpans除了重新使用接口外,还必须在ThreadCache中空出哈希(没有空出是问题)。
当然,手动调用毕竟是不友好的,而且会发生忘记调用的情况,这也是后续优化点,因此它的自动调用会以线程结束。