C#从根本上来说不可移植？
我使用 C# 一段时间了，最近开始为我的一个业余项目添加并行性。因此，根据 Microsoft 的说法，读取和写入整数，甚至浮点数是原子的
我确信这些原子性要求在 x86 架构上运行得很好。然而，在 ARM（可能没有硬件浮点支持）等架构上，这些保证似乎很难。
由于“int”始终是 32 位，这个问题变得更加严重。许多嵌入式设备无法自动执行 32 位写入。
看来这是 C# 中的一个根本错误。保证这些数据类型的原子性无法移植。
这些原子性保证如何在没有 FPU 或 32 位写入的架构上实现？
I've been using C# for a while, and have recently started working on adding parallelism to a side project of mine. So, according to Microsoft, reads and writes to ints and even floats are atomic
I'm sure these atomicity requirements workout just fine on x86 architectures. However, on architectures such as ARM (which may not have hardware floating point support), it seems these guarantees will be hard.
The problem is only made more significant by the fact that an 'int' is always 32-bits. There are many embedded devices that can't atomically perform a 32-bit write.
It seems this is a fundamental mistake in C#. Guaranteeing the atomicity of these data types can't be done portably.
How are these atomicity guarantees intended to be implemented on architectures where there are no FPUs or 32-bit writes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
通过运行时检查来保证原子性并不太困难。当然，如果您的平台支持原子读取和写入，您的性能可能会有所下降，但这是一个平台的权衡。
底线：C#（核心语言，不包括一些特定于平台的 API）与 Java 一样可移植。
It's not too difficult to guarantee the atomicity with runtime checks. Sure, you won't be as performant as you might be if your platform supported atomic reads and writes, but that's a platform tradeoff.
Bottom line: C# (the core language, not counting some platform-specific APIs) is just as portable as Java.
未来就发生在昨天，C#事实上已经被移植到大量的嵌入式内核中。 .NET Micro Framework 是典型的部署场景。我看到列为本机目标的型号有 AT91、BF537、CortexM3、LPC22XX、LPC24XX、MC9328、PXA271 和 SH2。
我不知道他们的核心指令集的具体实现细节，但我相当确定这些都是 32 位核心，其中有几个是 ARM 核心。为它们编写线程代码需要最低限度的保证，正确对齐的单词的原子更新就是其中之一。鉴于支持的列表以及对齐字的 4 字节原子更新在 32 位硬件中实现起来很简单，我相信它们实际上都支持它。
The future happened yesterday, C# is in fact ported to a large number of embedded cores. The .NET Micro Framework is the typical deployment scenario. Model numbers I see listed as native targets are AT91, BF537, CortexM3, LPC22XX, LPC24XX, MC9328, PXA271 and SH2.
I don't know the exact implementation details of their core instruction set but I'm fairly sure that these are all 32-bit cores and several of them are ARM cores. Writing threaded code for them requires a minimum guarantee and atomic updates for properly aligned words is one of them. Given the supported list and that 4 byte atomic updates for aligned words is trivial to implement in 32-bit hardware, I trust they all do in fact support it.
关于“可移植性”有两个问题：
语言提供的保证越强，将其移植到各种平台就越困难（某些保证可能导致在某些平台上实现该语言变得不可能或不切实际），但用该语言编写的程序就越有可能无需修改即可在任何支持的平台上工作。
例如，许多网络代码依赖于这样一个事实：（在大多数平台上）无符号字符是八位，而 32 位整数由四个无符号字符按升序或降序表示。我使用过一个平台，其中 char 为 16 位，sizeof(int)==1，sizeof(long)==2。编译器作者可以让编译器简单地使用每个地址的底部 8 位，或者可以添加很多额外的代码，以便编写“char”指针将地址右移一位（保存 lsb），读取地址，根据保存的地址LSB更新高半部分或低半部分，并将其写回。这些方法中的任何一种都允许网络代码无需修改即可运行，但会极大地妨碍编译器用于其他目的的有用性。
CLR 中的一些保证意味着在任何原子操作大小小于 32 位的平台上实现它都是不切实际的。所以呢？如果微控制器需要超过几十 KB 的代码空间和 RAM，则 8 位和 32 位之间的成本差异非常小。由于没有人会在具有 32K 代码空间和 4K RAM 的部件上运行 CLR 的任何变体，因此谁会关心这样的芯片是否能够满足其保证。
顺便说一句，我确实认为在 C 规范中定义不同级别的功能会很有用；例如，许多处理器确实具有 8 位字符，可以使用联合将其组装成更长的单词，并且有许多实用代码利用了这一点。最好为处理此类事情的编译器定义标准。我还希望在系统低端看到更多标准，为 8 位处理器提供一些语言增强功能。例如，为一个函数定义重载会很有用，该函数可以采用运行时计算的 16 位整数、8 位变量或带有常量的内联扩展版本。对于常用的功能，它们之间的效率可能存在很大差异。
There are two issues with regard to "portability":
The stronger the guarantees made by a language, the harder it will be to port it to various platforms (some guarantees may make it impossible or impractical to implement the language on some platforms) but the more likely it is that programs written in the language will work without modification on any platform for which support exists.
For example, a lot of networking code relies upon the fact that (on most platforms) an unsigned char is eight bits, and a 32-bit integer is represented by four unsigned chars in ascending or descending sequence. I've used a platform where char was 16 bits, sizeof(int)==1, and sizeof(long)==2. The compiler author could have made the compiler simply use the bottom 8 bits of each address, or could have added a lot of extra code so that writing a 'char' pointer would shift the address right one bit (saving the lsb), read the address, update the high or low half based upon the saved address lsb, and writing it back. Either of those approaches would have allowed the networking code to run without modification, but would have greatly impeded the compiler's usefulness for other purposes.
Some of the guarantees in the CLR mean that it is impractical to implement it in any platform with an atomic operation size smaller than 32 bits. So what? If a microcontroller needs more than a few dozen Kbytes of code space and RAM, the cost differential between 8-bit and 32-bit is pretty small. Since nobody's going to be running any variation of the CLR on a part with 32K of code space and 4K of RAM, who cares whether such a chip could satisfy its guarantees.
BTW, I do think it would be useful to have different levels of features defined in a C spec; a lot of processors, for example, do have 8-bit chars which can be assembled into longer words using unions, and there is a lot of practical code which exploits this. It would be good to define standards for compilers which work with such things. I would also like to see more standards at the low end of the system, making some language enhancements available for 8-bit processors. For example, it would be useful to define overloads for a function which can take a run-time-computed 16-bit integer, an 8-bit variable, or an inline-expanded version with a constant. For often-used functions, there can be a big difference in efficiency among those.
这就是 CLI 的用途。我怀疑如果实施不合规，他们是否会对其进行认证。所以基本上，C# 可以移植到任何拥有该平台的平台。
That's what the CLI is for. I doubt they will certify an implementation if it isn't compliant. So basically, C# is portable to any platform that has one.
为了可移植性而过度削弱保证，违背了可移植性的目的。保证越强，可移植性就越有价值。目标是在可能的目标平台可以有效支持的内容与对开发最有用的保证之间找到适当的平衡。
Excessively weakening guarantees for the sake of portability defeats the purpose of portability. The stronger the guarantees, the more valuable the portability. The goal is to find the right balance between what the likely target platforms can efficiently support with the guarantees that will be the most useful for development.