关于多线程共享大数据量的hash_map的问题

[wwx0202]

我的问题描述如下：
用一个hash_map存储一个最大pair数达到几十万条的用户简单信息，由多个线程共享。
大概有三种情况：向hash_map里添加一条记录，查询一条记录，删除记录。
要进行同步，由于对hash_map的访问频率很高，如果只对hash_map使用读写锁，那么线程挂起的情况将非常严重。
我想模仿数据库的多粒度锁机制来提高效率。即对hash_map和pair采取不同的策略，当添加记录时对hash_map写锁定，而删除记录时对pair写锁定，查询时则只对pair读锁定。
请教各位达人，此方法是否具有可行性？还有就是这么多的读写锁开销大到什么程度？还有什么更好的方法吗？由于没有分了，所以只给了10分，先谢谢各位了

[mLee79]

如果这点规模的数据都跑不过数据库又太搞笑了点 ...
不知道 overcomeunicom990702 在说什么, hash 表是hash表, rbtree+hash 不知道指的是什么, 偶用过rbtree解决冲突,不过好像跟你说的好像不搭边 ...
接近标准的 stdext::hash_map 在这种场合使用是不恰当的, 加锁的粒度不好控制, hashmap 是个非常简单的数据结构, 不知道为什么不自己实现个 ...

[abupie]

由于对hash_map的访问频率很高
具体高到什么程度？你的硬件如何？访问的模型是怎样的（集中？分散？有什么特征？）

分析好这些，再决定是否需要用锁，怎么样用锁，用什么样的锁。

[herman~~]

建议使用lockfree技术实现
具体实现代码就不贴了，自己google下，关键是做成无锁的线程安全，会使用到CAS ,CAS2等原语

[wwx0202]

[Quote=引用 2 楼 taodm 的回复:]
算了，你还是直接用数据库吧。
等你实现了足够强的并发保护后，和直接用数据库也已经没区别了。
[/Quote]
我的pair里存的是用户id和一个指向存储用户详细信息的一个指针，所有用户或系统要获得该用户的信息都会访问该hash_map，用数据库效率是否很低？

[taodm]

效率低不低的问题，只有你自己实测了才知道。

[overcomeunicom990702]

[Quote=引用 12 楼 mLee79 的回复:]
如果这点规模的数据都跑不过数据库又太搞笑了点 ...
不知道 overcomeunicom990702 在说什么, hash 表是hash表, rbtree+hash 不知道指的是什么, 偶用过rbtree解决冲突,不过好像跟你说的好像不搭边 ...
接近标准的 stdext::hash_map 在这种场合使用是不恰当的, 加锁的粒度不好控制, hashmap 是个非常简单的数据结构, 不知道为什么不自己实现个 ...



[/Quote]
lz一开始是说hash-map，没看过hash-map的实现，怀疑它是rbtree+hash实现
如果是这样的话，那样是有总题的，如果两个线程根据key得到两个不同的hash值，根据这两个hash值得到两把不同的锁（假定），都需要对rbtree进行改动（插入/删除所导致的旋转，修正），那么这时两个线程都对同一个rbtree进行改动，没有 同步，会导致错误
你说的rbtree解决冲突是指啥？

[overcomeunicom990702]

[Quote=引用 11 楼 arong1234 的回复:]
不要以为hash table很高效，他和人家做商业数据库软件的是没法比的
[/Quote]
杀鸡用牛刀？没必要，肯定比商业数据库快，特别是你所谓的商业的oracle，这里没有数据模型，单表而已

[overcomeunicom990702]

[Quote=引用 14 楼 cyblueboy83 的回复:]
建议使用lockfree技术实现
具体实现代码就不贴了，自己google下，关键是做成无锁的线程安全，会使用到CAS ,CAS2等原语
[/Quote]
这个太吓人了吧
lockfree研究很久了，到现在能够拿出来并且能够经受住考验的有几个？这个的难度太大了。
网上google一下，有个map的lockfree实现

[wwx0202]

[Quote=引用 14 楼 cyblueboy83 的回复:]
建议使用lockfree技术实现
具体实现代码就不贴了，自己google下，关键是做成无锁的线程安全，会使用到CAS ,CAS2等原语
[/Quote]

看了你说的lock free技术，确实很好，很强大。正在研读中，看自己是否能领会一二并用到我的代码中。

另外，看了楼上各位的建议，我想大概有这几种方案：使用数据库，细粒度锁，以及lock free，和其他。
结合我自己的实现力，我还是先使用用细粒度锁，看效率能否达到期望，如不行则再使用其它的方案吧。

再次感谢各位的建议，谢谢。

希望大家能继续讨论，所谓理补辩不明嘛。哈哈。

[arong1234]

不要小瞧这个单表，多线程情况下问题无穷无尽。不知道你做过几个多线程的大系统没有？有时即使很简单的应用都很难调试的。有些东西不能停留在“理论”分析，要实际做做。希望楼主是多线程的高手，能替你验证这个freelock吧
[Quote=引用 16 楼 overcomeunicom990702 的回复:]
引用 11 楼 arong1234 的回复:
不要以为hash table很高效，他和人家做商业数据库软件的是没法比的

杀鸡用牛刀？没必要，肯定比商业数据库快，特别是你所谓的商业的oracle，这里没有数据模型，单表而已
[/Quote]

[overcomeunicom990702]

[Quote=引用 19 楼 arong1234 的回复:]
不要小瞧这个单表，多线程情况下问题无穷无尽。不知道你做过几个多线程的大系统没有？有时即使很简单的应用都很难调试的。有些东西不能停留在“理论”分析，要实际做做。希望楼主是多线程的高手，能替你验证这个freelock吧
引用 16 楼 overcomeunicom990702 的回复:
引用 11 楼 arong1234 的回复:
不要以为hash table很高效，他和人家做商业数据库软件的是没法比的

杀鸡用牛刀？没必要，肯定比商业数据库快，特别是你所谓的…
[/Quote]
没啥大项目经验，以前依靠apache干活，就是做跟数据库相关的
worker模型，多进程多线程，每个请求都会涉及到数据库的访问，2至强双核/4核都玩过
性能满足要求，之前是用开源的现成数据库，性能瓶颈，后来改成hash＋lock，弄成可配的细粒度锁，没总题
ps:仍不看好lock free，这个东西需要硬件配合

[laolaoliu2002]

用"读--拷贝"的方法

[wwx0202]

[Quote=引用 21 楼 laolaoliu2002 的回复:]
用"读--拷贝"的方法
[/Quote]

能否详细说下呢？

[simon031187]

单开一条线程专门管理hash_map，就不用加锁，通过线程之间通讯来传递数据

[wwx0202]

[Quote=引用 23 楼 simon031187 的回复:]
单开一条线程专门管理hash_map，就不用加锁，通过线程之间通讯来传递数据
[/Quote]

大约似乎好像是个好办法，作为备选方案了。

[wwx0202]

[Quote=引用 23 楼 simon031187 的回复:]
单开一条线程专门管理hash_map，就不用加锁，通过线程之间通讯来传递数据
[/Quote]

大约似乎好像是个好办法，作为备选方案了。

[laolaoliu2002]

看看linux内核2.6.18以后进程部分的设计原理

[overcomeunicom990702]

[Quote=引用 23 楼 simon031187 的回复:]
单开一条线程专门管理hash_map，就不用加锁，通过线程之间通讯来传递数据
[/Quote]
你说的这个就是把它弄成CS模式吧，没啥效果的

[meiZiNick]

支持搂主，收藏

[overcomeunicom990702]

刚刚看了一下stl 的hash_map源码，就是一个hash table