Int64(长)和线程安全

发布于 2024-09-12 05:38:14 字数 272 浏览 4 评论 0原文

引用自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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

缺⑴份安定 2024-09-19 05:38:14

有可能,但为什么你要编写一个在某些英特尔类似平台上线程安全的程序,而在其他平台上却不然呢?请注意,DecimalDouble 类型也有关于线程安全的免责声明。

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 and Double 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

把时间冻结 2024-09-19 05:38:14

如果内存加载/存储操作是在放置在对齐内存地址上且不大于本机机器大小指针的内存块上执行的,则内存加载/存储操作被认为是原子的。
这意味着,在 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 the Interlocked class, but is available in native code).

For more details, check Joe Duffy's post: Thread-safety, torn reads, and the like.

非要怀念 2024-09-19 05:38:14

如果您的 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.

方觉久 2024-09-19 05:38:14

为了安全起见,我认为不会。

请注意这个上一个问题。本质上,对于 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".

梦情居士 2024-09-19 05:38:14

这里问题的关键是 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.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文