CPU 的设计跟着软件需求走的又一步: STM

[redsea]

lock-free datastructure, STM 等等, 在高并发的程序里面优点很多, Intel 开始考虑硬件直接支持这些东西了.

It seems an Intel research project is considering hardware support
for
transactional memory.

http://video.google.com/videoplay?docid=-5240896304418824367

BTW:
multi core 应用普遍以后, fp 语言不用改变就自然适应了, 传统的过程语言, OO 语言反而麻烦或者代价高.

特别是 OO 语言, 传统的设计上层次都比过程语言多, 小型的对象/内存分配量比过程语言多很多, 内存申请, 释放成为一个同步/性能的热
点. 记得以前见过一个案例, java 的一个服务器程序, bottleneck 都卡在内存申请和gc 上了.

[pongba]

有意思:) STM的概念太漂亮了，再加上的确也很practical。intel支持也是意料中事啊:)

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[Googol Lee]

不知道这次C++ 0x的并发模型会是什么样。如果走好了，说不定能引领潮流。

[jiaxiong xu]

lock-free跟pthread_rwlock/fcntl调用，其优点在哪？
考虑时刻1事务1修改数据1，时刻2事务2修改数据1，时刻2>时刻1，那么是不是有这么一种可能性，时刻2事务2对数据1的修改成功了，然后时刻1的事务1再修改数据1。如果这样的那，那lock-free的使用岂不再受限制？
比如银行更新汇率，10点钟更新美金与人民币汇率，11点钟再更新一下，结果11点钟的数据先更新过去了，再更新10点钟的

在07-9-14，Googol Lee <goog...@gmail.com> 写道：

[red...@gmail.com]

再过几年, 系统里面有都有几十的 core 的时候, 再用lock 干活, 那么整天等待
其他线程释放锁了, 系统的地址总线也要因为隔不了多少个时钟周期就要进行
cache 同步/cache line invalid 之类的变得低效无比.

解决这些问题, 就要靠 lock free 算法了, lock free 但是可以实现同步.

linux kernel 都已经再用了.

jiaxiong xu 写道:

[longshanksmo]

这些东西原本就该是硬件支持的。硬件拥有很多语言不知道的信息。

[jiaxiong xu]

-_-
redsea的回答还是没有去除我的疑惑啊
象我说的这种情况，lock-free究竟能不能避免？我认为是不行

在07-9-14，red...@gmail.com < red...@gmail.com> 写道：

[lijie]

lock-free提供的只是lock以外的另一种方式，最终要达到的效果是一样的，只是它不锁总线，并不是说lock-free就不保证操作顺序了。

目前这方面看得少，主要了解的两种lock-free应用，环形队列和CMPXCHG，前一种主要用于生产者/消费者队列，后一种主要是共享方式。目前用过的只有前一种，效率提升是肯定有的，但目前应用过的场合都不能让它表现得很明显，一个4CPU机器上每秒处理能力从35200次提升到35500次，主要是因为瓶颈并不在同步队列这里。至于能不能避免你说的这个情况，这主要和实现方式有关，你说的情况如果真实发生的话，可以算作是错误的实现方式了。

在07-9-15，jiaxiong xu <jiaxi...@gmail.com> 写道：

[pongba]

你说的那种情况不会发生的，因为如果11点钟的汇率更新过了而10点钟的那个更新延迟了的话，延迟后就不能更新，会被丢弃。我blog上有两篇andrei写的lock-free的文章，C++实现，应该能解答你的问题。

[jiaxiong xu]

正是看了你blog上的两篇文章后才觉得lock-free在这种情况下不能起作用

在07-9-15，pongba <pon...@gmail.com> 写道：

[red...@gmail.com]

我已经回答过你啊 "lock free 但是可以实现同步."

你可以认为 lock, lock free 算法就是数据库的悲观方法(加锁), 乐观方法(处理完毕之后
检查版本冲突) 在更细粒度的实现吧. postgres 一直用乐观方法, oracle 最近的版本也支
持乐观方法了,

乐观方法可以在实际冲突发生比率低的时候, 避免花时间在加解锁上面, 同时增加了并发度.

如果冲突几率相当高, 还是悲观方法效率好.

lock, lock-free 算法和这些差不多.

jiaxiong xu 写道:

正是看了你blog上的两篇文章后才觉得lock-free在这种情况下不能起作用

在07-9-15，pongba <pon...@gmail.com> 写道：

你 说的那种情况不会发生的，因为如果11点钟的汇率更新过了而10点钟的那个更新延迟了的话，延迟后就不能更新，会被丢弃。我blog上有两篇andrei 写的lock-free的文章，C++实现，应该能解答你的问题。

On 9/15/07, jiaxiong xu < jiaxi...@gmail.com> wrote:

-_-
redsea的回答还是没有去除我的疑惑啊
象我说的这种情况，lock-free究竟能不能避免？我认为是不行

在07-9-14，red...@gmail.com < red...@gmail.com> 写道：

再 过几年, 系统里面有都有几十的 core 的时候, 再用lock 干活, 那么整天等待

[李一楠]

同感。顺序语义问题和访问竞争问题是两回事。 

---

网 易 Yeah.net 邮 箱 夏 日 大 变 脸，带 你 感 受 新 一 代 邮 箱 的 全 新 魅 力 >>

[pongba]

似乎就算冲突高，也可以用"乐观+冲突resolve"的方法来办，我还没有看相关paper。哪位知道介绍一下？:) 比如windows某个版本（似乎是XP吧），当一个线程获得锁并执行的时候，就会暂时提高它的优先级，时间片用完再降低回去，这样可以避免同优先级上的多个线程出现lock convovy（见wiki）的情况。我的意思是，就（思想上）类似这样的解冲突手段，也可以用来辅助乐观执行的。