求救前辈们

[mars_heart]

我正进行实时数据库的开发。处理并发让我头痛了好久了。跨进程多个写，与多个读。写的时候不允许写也不允许读，读的时候不允许写但可以读。因为实时库读写频繁，同时要考虑高效实时性。请高人指点。

[mars_heart]

我目前设计的实时库基于oo按分层来考虑的，以链表支链方式管理。数据访问检索采用hash算法。对于数据点客户端除主动读一次数据以后，都采用消息触发机制去读，所以对于数据点的读写冲突存在应该比较少，准备直接每个数据点采用一个锁标，一个等待数，外加一个记录全局数据点冲突的信标。这样因为大部分时间不出现冲突效率很高，因为冲突分散到数据层。
但是目前我遇到的为题是hash表的维护，因为采集端与客户端通过点名访问，每次写数据或主动读数据都需要查询hash表。这样当进行数据点添加或删除时hash表需添加或删除时势必与读写发生冲突。而这个冲突的解决对实时库响应速度影响很大。为了防止冲突需要多个锁标示与变量来控制，而跨进成不能使用关键代码段，必须使用内核同步机制。这样在维护锁标示与冲突控制变量就使用内核同步，hash检索也不能并行实现效率就低了。所以一直苦闷中。
我不知道我表述不清楚还是怎么回事，这个问题简单点使用互斥体，或其它内核同步对象都可以解决，但实时库数据交换量大，要求响应速度快。我一直在尝试使用互锁函数来控制，但没有找到好的解决办法。问题在“hash检索时可以检索，但不能添加或删除hash节点（hash采用静态桶结合拉链的方式），进行hash表添加或删除节点时不允许检索”。求最优算法。

[蒋晟]

http://community.csdn.net/IndexPage/SmartQuestion.aspx#bespecific

[一条晚起的虫]

数据库的并发处理不外乎那么几种。

[CathySun118]

具体点吧

[mars_heart]

在网上看了些东西，我维护的hash表记录了点名，与TAG对象的地址。采用静态桶结合拉链，准备采用记录锁的方式，及另外维护一个和hash表KEY值范围大小的锁数组。我测试过拉链长度16229静态桶，插入10000个随机字符串，最大拉链长度为7。一个记录锁最多锁住7个点。当客户端访问实时库时，先获得记录锁再进行操作。hash表结点的添加删除同样得到了维护。不准备采用内核方式，想采用循环锁发生冲突时switchthread方式放弃时间片，循环几次还不能成功获得锁则放弃操作报错。
不知道这样是否够好。

[ReverseEngineering]

貌似可以