Obj-C 2.0のプロパティのドキュメントでは、アトミックプロパティは内部的にロックを使用しますが、ロックの詳細は記録されません。これは、プロパティごとのロック、@synchronized（self）で使用される暗黙のロックとは別のオブジェクト単位のロック、または@synchronized（self）と同等のものであるかどうかは誰にも分かりますか？Obj-C 2.0で合成されたatomic @propertiesのロックの詳細をロックする
アトミック@propertiesで使用されるロックは実装の詳細です。適切なタイプの適切なプラットフォームでは、ロックのないアトミックな操作が可能で、アップルがそれらを利用していなかったら驚くでしょう。どのような場合でもロックへのパブリックアクセスはないので、同じロックで@synchronizeすることはできません。いくつかのアップルのエンジニアは、原子の性質がスレッドの安全性を保証するものではないことを指摘しています。原子プロパティは、その値の取得/設定がアトミックであることのみを保証します。正しいスレッドの安全性を確保するには、より高いレベルのロックまたは同期を使用する必要があります。また、合成ゲッター/セッターが使用しているロックと同じロックを使用することはほとんどありません。
生成されたコード（ARM用のiOS SDK GCC 4.0/4.2）を見ると、（struct {int32_t v;}含む）
assign特性が直接アクセスされます。doubleとint64_tはobjc_copyStructでアクセスされますが、stmia/ldmiaで直接アクセスされるGCC 4.0は例外です（割り込みの場合はアトミックであることが保証されているかどうかはわかりません）。Cocoa with Love: Memory and thread-safe custom property methodsは、実装方法に関する詳細をruntime version objc4-371.2で示しています。明らかに正確な実装はランタイムによって異なる場合があります（たとえば、あるプラットフォームでは、別のロックを使用する代わりに、アトミックスワップ/ CASを使用してivar自体を回転させることができます）。
はい、「man atomic」を参照してください。 –
同時に複数のプロパティを扱うときに、原子プロパティと@synchronized（）の両方を使用するために余分なオーバーヘッドがあるかどうか疑問に思っていたので、私は尋ねていました。アトミックプリミティブを使用して実行できない操作の場合、2つのロックを効果的に使用するため、余分なオーバーヘッドが発生するようです。まぁ。 –
この場合、より高いレベルのロックセマンティクスを実装するためにすでに@synchronizedブロックまたは他の方法で保護されたブロックを使用している場合は、非構造を使用してプロパティに使用することができます。 –