标签 linux
<分区>
我正在考虑将生成大量复杂数据表的旧驱动程序移植到用户空间中 - 因为这些表已经变得足够大，内存消耗成为一个严重的问题。
由于性能很关键，而且会有 16-32 个数据同时读取者，我们认为我们会用共享内存模型替换旧的基于/dev 的代码接口(interface)，这样客户端就可以直接搜索表而不是直接查询守护进程。
问题是 - 最好的方法是什么？我可以直接使用 shm_open()，但这可能需要我设计自己的记录锁定，甚至可能需要为共享内存设计一个 ISAM 数据结构。
与其编写自己的代码重温 1970 年代，有没有提供基于散列的查找机制的高性能共享内存 API？数据完全是数字，搜索关键字是固定长度的位域，长度可以是 8、16 或 32 个字节。
最佳答案
这是我想写一段时间的东西，但总是有更紧迫的事情要做......
仍然，对于共享键数据 RAM 存储的大多数用例，memcached将是最简单的答案。
在你的情况下，它看起来像是较低级别的，所以它 memcached，虽然速度很快，但可能不是最好的答案。我会尝试 Judy Arrays在 shmem block 上。它们非常快，因此即使您使用简单的锁来封装访问，您仍然可以获得高性能访问。
对于更复杂的任务，我会搜索无锁结构(一些链接:1、2、3、4)。我什至写了one前段时间，用hopes将其集成到 Lua 中内核，但事实证明很难与现有的实现保持一致。不过，它可能会让您感兴趣。
关于linux - 有人可以建议支持复杂数据的高性能共享内存 API 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1505748/