私はしばらくの間 C# を使用しており、最近、サイド プロジェクトに並列処理を追加する作業を開始しました。したがって、Microsoft によれば、int や float への読み取りと書き込みはアトミックです。
これらの原子性要件は、x86 アーキテクチャで問題なく機能すると確信しています。ただし、ARM などのアーキテクチャ (ハードウェア浮動小数点がサポートされていない可能性があります) では、これらの保証は難しいようです。
この問題は、「int」が常に 32 ビットであるという事実によってのみ、より重要になります。32 ビット書き込みをアトミックに実行できない組み込みデバイスが多数あります。
これは C# の根本的な間違いのようです。これらのデータ型の原子性を保証することは移植可能ではありません。
これらの原子性保証は、FPU や 32 ビット書き込みがないアーキテクチャでどのように実装されることを意図していますか?
実行時チェックで原子性を保証することはそれほど難しくありません。確かに、プラットフォームがアトミックな読み取りと書き込みをサポートしている場合ほどのパフォーマンスは得られませんが、それはプラットフォームのトレードオフです。
結論: C# (一部のプラットフォーム固有の API を除いたコア言語) は、Java と同じくらい移植性があります。
未来は昨日起こりました。C# は実際に多数の組み込みコアに移植されています。.NET Micro Framework は、典型的な展開シナリオです。ネイティブ ターゲットとしてリストされているモデル番号は、AT91、BF537、CortexM3、LPC22XX、LPC24XX、MC9328、PXA271、および SH2 です。
コア命令セットの正確な実装の詳細はわかりませんが、これらはすべて 32 ビット コアであり、そのうちのいくつかは ARM コアであることは確かです。それらのスレッド化されたコードを書くには最低限の保証が必要であり、適切に整列された単語のアトミックな更新はその 1 つです。サポートされているリストと、整列された単語の 4 バイトのアトミック更新を 32 ビット ハードウェアに実装するのは簡単であることを考えると、実際にはすべてがサポートしていると信じています。
「移植性」に関しては、次の 2 つの問題があります。
言語による保証が強ければ強いほど、さまざまなプラットフォームへの移植が難しくなります (保証によっては、一部のプラットフォームでその言語を実装することが不可能または非現実的になる場合があります)。しかし、その言語で書かれたプログラムは、サポートが存在するどのプラットフォームでも変更なしで動作します。
たとえば、多くのネットワーク コードは、(ほとんどのプラットフォームで) unsigned char は 8 ビットであり、32 ビット整数は昇順または降順の 4 つの unsigned char で表されるという事実に依存しています。私は、char が 16 ビット、sizeof(int)==1、および sizeof(long)==2 であるプラットフォームを使用しました。コンパイラの作成者は、コンパイラに各アドレスの下位 8 ビットを単純に使用させるか、「char」ポインタを書き込むとアドレスが 1 ビット右にシフトされ (lsb が保存される)、アドレス、保存されたアドレス lsb に基づいて上半分または下半分を更新し、それを書き戻します。これらのアプローチはいずれも、ネットワーク コードを変更せずに実行できますが、他の目的でのコンパイラの有用性を大きく妨げていました。
CLR の保証の一部は、32 ビット未満のアトミック操作サイズを使用してプラットフォームに実装することが実際的ではないことを意味します。だから何？マイクロコントローラーが数十キロバイト以上のコード空間と RAM を必要とする場合、8 ビットと 32 ビットのコスト差はごくわずかです。32K のコード空間と 4K の RAM を備えた部品で CLR のバリエーションを実行する人はいないので、そのようなチップがその保証を満たすことができるかどうかは誰が気にします.
ところで、C 仕様でさまざまなレベルの機能を定義すると便利だと思います。たとえば、多くのプロセッサには、ユニオンを使用してより長い単語に組み立てることができる 8 ビットの char があり、これを利用する実用的なコードがたくさんあります。そのようなもので動作するコンパイラの標準を定義することは良いことです. また、システムのローエンドでより多くの標準を見て、8 ビット プロセッサで利用できる言語の機能強化を望んでいます。たとえば、実行時に計算された 16 ビット整数、8 ビット変数、またはインライン展開されたバージョンの定数を受け取ることができる関数のオーバーロードを定義すると便利です。よく使われる機能については、それらの間で効率に大きな違いが生じる可能性があります。
それがCLIの目的です。実装が準拠していない場合、実装が認証されるとは思えません。したがって、基本的に、C# は、C# を持つすべてのプラットフォームに移植できます。
移植性のために過度に保証を弱めることは、移植性の目的を無効にします。保証が強いほど、移植性が高くなります。目標は、ターゲット プラットフォームが効率的にサポートできるものと、開発に最も役立つ保証との間の適切なバランスを見つけることです。