4

私はこの質問（および他のいくつかの質問）を読みました：

アトミック属性と非アトミック属性の違いは何ですか？

プロパティのアトミック/非アトミック指定子がどのように機能するかを完全に理解しています（少なくともそう願っています:-D）。

  1. Atomicは、「読み取り」操作が「書き込み」操作によって中断されないことを保証します。Nonatomicはこれを保証するものではありません。

  2. アトミックでも非アトミックでも、1つのスレッドが読み取りを行い、2つのスレッドが書き込みを行う競合状態を解決しません。読み取り操作がどのような結果を返すかを予測する方法はありません。これは、追加の同期によって解決する必要があります。

  3. アトミックでも非アトミックでも、全体的なデータの整合性を保証するものではありません。1つのスレッドが1つのプロパティを設定し、別のスレッドが2番目のプロパティを最初のプロパティの状態と矛盾する状態に設定する可能性があります。これは、追加の同期によっても解決する必要があります。

私の眉を上げるのは、人々が2つのキャンプに分かれていることです。

プロアトミック：nonatomicパフォーマンスの最適化にのみ使用するのが理にかなっています。

また、最適化していない場合は、ポイント1のため、常にアトミックを使用する必要があります。これにより、マルチスレッドアプリケーションでこのプロパティを読み取るときに、完全ながらくたを取得することはありません。そして確かに、ポイント2と3を気にする場合は、その上に同期を追加する必要があります。

アトミックに対して：アトミックを使用することはまったく意味がありません。

アトミックはマルチスレッドアプリケーションのすべての問題を解決するわけではないため、とにかく同期コードを追加する必要があるため、アトミックを使用しても意味がありません。それは物事を遅くするだけです。

私はプロアトミックキャンプに傾倒していますが、何も見逃していないことを確認するために健全性チェックを行いたいと思います。

4

1 に答える 1

6

非常に具体的な質問がありませんが（それでも良い質問ですが）、私は個人的な経験、FWIWで答えます。

一般に、並行性の設計は困難です。GCDやARCのような最新の便利さにより、並行システムを実装するためのツールは確かに改善されました。ただし、並行性のアーキテクチャは依然として非常に困難です。

そして、一般的に、難しい部分は個々のプロパティとは何の関係もありません。個々のゲッターとセッター。並行性は、より高いレベルで実装されるものです。

現在の最先端技術は、単独での並行性です。つまり、同時に実行されているアプリの部分は、アプリケーションの残りの部分への接続が非常に少ないオブジェクトの分離されたグラフを使用して実行しています（通常、「接続」は、状態とトスのビットをバンドルするコールバックを介して行われます他のキュー（多くの場合、UIを更新するためのメインキュー）に転送されます。

同時実行の表面積（同時実行に対して安全でなければならないコードへのエントリポイントの数）を最小限に抑えることで、複雑さと、非常に奇妙で再現不可能な同時実行の問題のデバッグに費やす時間の両方を削減できます。 （それはあなたの正気で食べるでしょう）。

これらすべてを考慮すると、アトミックプロパティの値はごくわずかです。確かに、それらは、複数のスレッドから強打される可能性のある非常に小さなインターフェイスのセット（APIの）に沿って役立つ可能性がありますが、それだけです。

アクセサが急速に攻撃されているオブジェクトがある場合、それらをアトミックにすることはパフォーマンスに大きな打撃を与える可能性がありますが、時期尚早の最適化は悪魔の指です。

于 2013-02-15T21:08:29.883 に答える