C 的 STM 哈希库（glib？）
我正在寻找一些包含 STM 风格（软件事务内存）哈希映射的 C 库，但到目前为止我还没有运气。如果它基于 glib / gobject 那就太好了，但这并不是那么重要。它也不需要对许多对象进行适当的事务 - 我真正需要的是单个不可变哈希支持。
必须具备：不可变的快照读取、带自动重试的无锁写入。
I'm looking for some C library that includes STM-style (Software Transactional Memory) hash maps, but I had no luck so far. It would be great if it was based on glib / gobject, but it's not that crucial. It also doesn't need proper transactions over many objects - single immutable hash support is all I really need.
Must haves: immutable snapshot read, lock-free write with auto-retry.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
维基百科有各种STM 实现的列表。
Wikipedia has a list of various STM implementations.
嗯，我认为（并且有很多研究）当前的 STM 并不比无锁和基于互斥的代码更快。显而易见：STM需要在线数据冲突检查。然而，纯软件中的这种冲突检查需要非常巨大的时间开销。目前，只有 Sun 的 ROCK 处理器 支持有限形式的 STM （尽力而为的 HTM 与 STM）通过硬件。目前没有 x86 CPU 在硬件上支持 TM。简而言之，STM 就是慢。
在我看来，你最好只使用并发哈希表。例如，您可以在英特尔 TBB 中找到
concurrent_hash_map。这是TBB 手册的链接。哦，但它是 C++，而不是 C。但是，我确实相信您可以（尽管这可能需要大量工作）将基于 C++ 的此类哈希表转换为 C 代码。英特尔 TBB 是开源的。另外，我认为这种高度并发（通常实现为无锁）的数据结构并不总是有用。在某些工作负载模式中，使用这样的数据结构并不好。可以肯定的是，我建议您为两个版本的哈希表编写一个小型微基准：(1) 无锁和 (2) 基于锁。另外，请记住，此类微基准的工作负载模式应接近真实情况。可以在此处找到示例。
Well, I think (and there are a number of study) that current STM isn't faster than lock-free and mutex-based code. It is obvious: STM requires on-line data conflict checking. However, such conflict checking in pure software requires very huge time overheads. Currently, only Sun's ROCK processor supports a limited form of STM (Best-effort HTM with STM) by hardware. No x86 CPUs currently support TM in hardware. In short, STM is just slow.
In my opinion, you'd better just using a concurrent hash table. For example, you can find
concurrent_hash_mapin Intel TBB. Here is the link of TBB Manual. Oh, but it's C++, not C. But, I do believe you can (though it might take significant work) translate C++-based such hash table to C code. Intel TBB is open source.Also, I think such highly concurrent (usually implemented as lock-free) data structures are not always useful. In some workload pattern, using such data structures is not good. To be sure, I recommend you to write a small micro-benchmark for two versions of hash tables: (1) lock-free and (2) lock-based. Also, please keep in mind the workload patterns for such micro-benchmark should be close to real one. An example could be found in here.
TBoost.STM 在其示例中实现了哈希映射。
TBoost.STM has implemented a hash map in its example.