Int64(长)和线程安全
引用自MSDN
分配这种类型的实例在所有硬件平台上都不是线程安全的,因为该实例的二进制表示可能太大而无法在单个原子操作中分配。
这是否意味着 Thead 在 Itianium 或 x86-64 等 64 位处理器上也是安全的?
例如:
long data = GetData();
// some parallel task on data
可能有问题吗?
A quote from MSDN
Assigning an instance of this type is not thread safe on all hardware platforms because the binary representation of that instance might be too large to assign in a single atomic operation.
Does it mean is that Thead-safe on 64bit processors like Itianium or x86-64 as well?
For instance:
long data = GetData();
// some parallel task on data
Could be a problem?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
有可能,但为什么你要编写一个在某些英特尔类似平台上线程安全的程序,而在其他平台上却不然呢?请注意,
Decimal
和Double
类型也有关于线程安全的免责声明。Microsoft 建议在这些情况下使用锁。这里有一些关于并发、内存映射和低级锁的好信息的链接:
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/f03ea3c9-4c2b-4a79-8f8c-4a6b7476b20d
Possibly, but why would you write a program that will be thread safe on some Intel workalike platforms, but not others? Note that the
Decimal
andDouble
types also have this disclaimer about thread safety.Microsoft recommends the use of locks in these cases. There are links to some good information about concurrency, memory mapping and low-level locks here:
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/f03ea3c9-4c2b-4a79-8f8c-4a6b7476b20d
如果内存加载/存储操作是在放置在对齐内存地址上且不大于本机机器大小指针的内存块上执行的,则内存加载/存储操作被认为是原子的。
这意味着,在 64 位平台上,对齐内存地址上的加载/存储操作在 64 位平台上将是原子的,但在 32 位平台上则不是原子的。
现代处理器提供了一组特殊的指令(在 .Net 中,大多数指令都是通过 Interlocked 类公开的)。允许在大于机器本机指针大小的加载/存储操作上实现原子性(32 位处理器上的 64 位操作和 64 位处理器上的 128 位操作。后者不是由 Interlocked 类公开的,但在本机代码中可用)。
有关更多详细信息,请查看 Joe Duffy 的帖子: Thread-安全、阅读内容撕裂等。
Memory load/store operations are considered to be atomic if they are performed on memory chunks that are placed on aligned memory address and are not bigger than the native machine-sized pointer.
Meaning, at 64bit load/store operation on an aligned memory address will be atomic on a 64bit platform, but it won't be atomic on a 32bit platform.
Modern processors offers a special set of instructions (in .Net, most of them are exposed via the
Interlocked
class). that allow to achieve atomicity on load/store operations that are larger than the machine's native pointer size (64bit operations on 32bit processors, and 128bit operations on 64bit processors. The latter isn't exposed by theInterlocked
class, but is available in native code).For more details, check Joe Duffy's post: Thread-safety, torn reads, and the like.
如果您的
data
变量由不同线程的代码直接访问,则会出现问题。他们不对任何特定系统做出保证,所以为了安全起见,我假设它在 x64 系统和 x86 上不是线程安全的,尽管我怀疑他们真正想到的是像智能手机上运行的紧凑框架这样的地方。
It's a problem if your
data
variable is accessed directly by code from different threads.They don't make guarantees about any specific system, so to be safe I'd assume it's not threadsafe on x64 systems as well as x86, though I suspect what they really had in mind was places like the compact framework running on smart phones.
为了安全起见,我认为不会。
请注意这个上一个问题。本质上,对于 Int64 的原子分配,您应该考虑使用 Interlocked 类。
查看此链接也可以获得一些更详细的分析。特别是,请查看标记为“原子性和互锁”的部分。
I would err on the safe side and assume not.
Note this previous question. Essentially, for atomic assignment to Int64s you should look at using the Interlocked class.
Check out this link also for some more detailed analysis. In particular, check out the section labeled: "Atomicity and Interlocked".
这里问题的关键是
Int64
不能保证是原子的,但这并不妨碍它在某些情况下是原子的。换句话说,Int64
在 64 位系统上是原子的。当然,这并不意味着它一定是线程安全的。除了原子性之外,还有其他关于线程安全的问题。例如,为了防止过时问题,您必须使用适当的内存屏障指令(易失性
、Thread.VolatileWrite
等)The crux of the matter here is that
Int64
is not guarenteed to be atomic, but that does not preclude it from being so in some cases. In other words,Int64
would be atomic on 64-bit systems. Of course, that does not mean it is necessarily thread-safe. There are other issues regarding thread-safety aside from atomicity. To guard against the staleness issue, for example, you would have to use the appropriate memory barrier directives (volatile
,Thread.VolatileWrite
, etc.)