long类型需要加锁吗？

cjaizss

依赖性的消除用“锁”（抽象意义的锁）不可避免，只是双口器件给你看到了表象，觉得相互之间各走各的，实际上，硬件内部带着锁呢

cjaizss

当然，看是什么样的双口器件了。比如有一种，一边只能写，一边只能读，读写同时发生的话，读的那边只给之前的存储，那么其实在这里读与写之间暂时在当前clock的瞬间已经没有任何依赖关系（也就是读的那边读出来的数据完全不取决于另外一边此时在不在写，在写的话写什么样的数据）；换一个策略也一样，读的那边不依赖于上一刻的状态。另外一种，两边可读写，内部有个“锁”（策略）在那里以防同时写的情况。

[ 本帖最后由 cjaizss 于 2008-12-20 00:33 编辑 ]

cjaizss

其实，换句话说，写是为了读，生产是为了消费。一口读一口写的双口的两种策略可以换种思路认为，一种是写的优先级高，写发生在读之前，而另外一种是读的优先级高，读发生在写之后。而一个状态机（在这里可能是处理器）的状态转移都是最少以clock为尺度来转移的，而双口的优先级不足该状态机的识别粒度，所以看起来没有影响它们什么。

fineamy

是，这个进入另一个层面了。
不管如何，这个依赖性从读写层面来说是实实在在的分开了。用锁是手段。
而对于有些数据依赖性在一定条件下确实是没办法消除的。比如CPU指令间的寄存器依赖性，是没办法完全消除的。就是常说的指令并行性。这才使得另辟蹊径。比如将若干条指令或者功能代码看作一个整体，而不是目光只在单条指令上，那么这些功能代码间确没有数据相关性或者很容易消除，这样就是多线程CPU核采取的方式了。

fineamy

其实，换句话说，写是为了读，生产是为了消费。一口读一口写的双口的两种策略可以换种思路认为，一种是写的优先级高，写发生在读之前，而另外一种是读的优先级高，读发生在写之后。而一个状态机（在这里可能是处理器）的状态转移都是最少以clock为尺度来转移的，而双口的优先级不足该状态机的识别粒度，所以看起来没有影响它们什么。

实现库怎么，不是很清楚，
但是如过用门电路搭的话，比如FPGA
同时读写还是可以的。两路读写，地址，数据分开。

Aquester

话题怎么成硬件了

cjaizss

原帖由 Aquester 于 2008-12-20 10:47 发表
话题怎么成硬件了

加锁还是不加锁,模型上不区分是软还是硬

mik

扯到十万八千里了

cjaizss

原帖由 mik 于 2008-12-20 22:01 发表


扯到十万八千里了

呵呵,只是展开说了说"锁"

mik

都是牛人，这个版涌出牛人呀。pfpf