是否可以不用锁?

[gel_ink]

int num 只在一个线程中被赋值(修改)
在另外一个的线程中读取它的值. int k = num;

这种情况不需要用锁?
在64位cpu上呢?

如果换成 char num, WORD num, 是否可以不用锁?

希望有intel方面的官方文档说明.

[gel_ink]

[Quote=引用 2 楼 intel_iclifort 的回复:]
读后写, 和写后读的结果一样么? 如果会出现不一样, 当然要保护了, 典型的竞争冲突(Race Condition)啊...

这个和你的硬件系统有几个CPU, CPU有几个核, 没有任何关系
[/Quote]

读后写? 写后读?
写后再读的结果肯定不同了,这有关系吗? 即使加锁保护后,结果也不同啊.
它的竞争在哪里?

[gel_ink]

我希望:
写值时,它可以成功完成,不会写错. 修改的一瞬间,应该是原子操作吧?
读值时,结果要么是写前的数值,要么是写后的数值,不会是其他的什么值.

[intel_iclifort]

[Quote=引用 3 楼 gel_ink 的回复:]
引用 2 楼 intel_iclifort 的回复:
读后写, 和写后读的结果一样么? 如果会出现不一样, 当然要保护了, 典型的竞争冲突(Race Condition)啊...

这个和你的硬件系统有几个CPU, CPU有几个核, 没有任何关系


读后写? 写后读?
写后再读的结果肯定不同了,这有关系吗? 即使加锁保护后,结果也不同啊.
它的竞争在哪里?
[/Quote]

竞争冲突, 是指这一类由于执行顺序不同, 可能会引起结果不正确的情况, 包括读后写, 写后读, 和写后写

你例子中的情况, 关键是读num后, 还有没有其它相关代码的运行结果, 会受到影响. 需要根据代码来具体分析

[gel_ink]

能否举个结果受影响的例子?

[intel_iclifort]

[Quote=引用 4 楼 gel_ink 的回复:]
我希望:
写值时,它可以成功完成,不会写错. 修改的一瞬间,应该是原子操作吧?
读值时,结果要么是写前的数值,要么是写后的数值,不会是其他的什么值.
[/Quote]

高级语言中, 能够转化为原子操作的非常有限, 受到不同硬件平台实现的限制. 举个例子, 累加在Windows里提供了相应的API, 在Linux里就没有

[gel_ink]

[Quote=引用 7 楼 intel_iclifort 的回复:]

高级语言中, 能够转化为原子操作的非常有限, 受到不同硬件平台实现的限制. 举个例子, 累加在Windows里提供了相应的API, 在Linux里就没有

[/Quote]

我的情况是 c++语言(vc2005), 写操作就是 num = m;

你说的Windows里提供了的累加API,指InterlockedIncrement()吧,
我的愿望是,虽然InterlockedIncrement()够快,
但它毕竟用了"memory barrier",而且还有函数的栈操作消耗,
所以最好也不用InterlockedXxx()函数. 做到分秒必争.

[gel_ink]

[Quote=引用 7 楼 intel_iclifort 的回复:]

高级语言中, 能够转化为原子操作的非常有限, 受到不同硬件平台实现的限制. 举个例子, 累加在Windows里提供了相应的API, 在Linux里就没有

[/Quote]

我的情况是 c++语言(vc2005), 写操作就是 num = m;

你说的Windows里提供了的累加API,指InterlockedIncrement()吧,
我的愿望是,虽然InterlockedIncrement()够快,
但它毕竟用了"memory barrier",而且还有函数的栈操作消耗,
所以最好也不用InterlockedXxx()函数. 做到分秒必争.

[gel_ink]

[Quote=引用 7 楼 intel_iclifort 的回复:]

高级语言中, 能够转化为原子操作的非常有限, 受到不同硬件平台实现的限制. 举个例子, 累加在Windows里提供了相应的API, 在Linux里就没有

[/Quote]

我的情况是 c++语言(vc2005), 写操作就是 num = m;

你说的Windows里提供了的累加API,指InterlockedIncrement()吧,
我的愿望是,虽然InterlockedIncrement()够快,
但它毕竟用了"memory barrier",而且还有函数的栈操作消耗,
所以最好也不用InterlockedXxx()函数. 做到分秒必争.

[intel_iclifort]

Atomic increment/decrement operations on 32/64 bit integer variables: http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/980382.aspx

64-bit atomic operations.: http://www.exit.com/blog/archives/000361.html

[gel_ink]

[Quote=引用 7 楼 intel_iclifort 的回复:]

高级语言中, 能够转化为原子操作的非常有限, 受到不同硬件平台实现的限制. 举个例子, 累加在Windows里提供了相应的API, 在Linux里就没有

[/Quote]

我的情况是 c++语言(vc2005), 写操作就是 num = m;

你说的Windows里提供了的累加API,指InterlockedIncrement()吧,
我的愿望是,虽然InterlockedIncrement()够快,
但它毕竟用了"memory barrier",而且还有函数的栈操作消耗,
所以最好不用InterlockedXxx()函数. 做到分秒必争.

[gel_ink]

csdn犯毛病了,点了很多次"提交"看不到结果,等看到结果时,出现了一堆. -- 题外话


我看了你给的英文链接,看得不是太懂,
大意好象是:
如果 num是按照 32-byte cache line 对齐(alignment)的, 就可以保证它是原子操作?

[gel_ink]

[Quote=Lexi S.(Intel(R) Software Network Support):]
Here, it is guaranteed that simple loads or stores will be automatically atomic as long as the memory location is aligned on the appropriate boundary (16-bit boundary for 16-bit values, 32-bit boundary for 32-bit values, and so forth).
[/Quote]

看起来好象是不需要同步锁了?

[gel_ink]

还要单核,多核的情况?

[intel_iclifort]

读后写, 和写后读的结果一样么? 如果会出现不一样, 当然要保护了, 典型的竞争冲突(Race Condition)啊...

这个和你的硬件系统有几个CPU, CPU有几个核, 没有任何关系