ClangLLVM/Objective-Cのatomic属性プロパティが保証する性質、C言語(C11)のAtomic変数アクセスとの比較、およびマルチスレッド処理での利用についてメモ。@property宣言には常にnonatomic属性を指定せよ。atomic属性プロパティは人類には早すぎる。この門をくぐる者は一切の希望を捨てよ。参照型atomic属性プロパティ@end注意:本記事の内容はLLVM/Clangコンパイラ出力から演繹的に導いた解析内容に基づく。Objective-Cの厳格な言語仕様は存在しない(?)。まとめ:Objective-C/スカラ型のatomic属性プロパティは、最も弱いアトミック性(Atomicity)しか保証しない。relaxedアクセスよりも弱い保証レベルである。*1スカラ型atomic属性プロパティの読込(Read)/書出(Write)操作は、文字通り不可分(Atomic)なメモリロード/ストア命令に変換されることのみ(→id:yohhoy:20121016)保証される。RMW(Read-Modify-Write)操作のアトミック性は保証されない。*2スカラ型atomic属性プロパティへのアクセスでは順序性(Ordering)が保証されず、スレッド間同期機構として用いることができない(→id:yohhoy:20140808)。いうスレッド間同期処理が、プログラマの期待通り動作する保証がない。コンパイラやプロセッサは、スレッドA/B上で行われる書出/読込アクセスの順序を入れ替える可能性がある。例2:ロック状態をatomic属性プロパティで表現したSpinlock同期機構は、順序性保証の欠如により排他制御として機能しない。コンパイラやプロセッサは、ロック範囲(クリティカルリージョン内)のメモリアクセス命令をその領域外へと移動する可能性がある。Atomic変数型_Atomic(T)を利用すること。Atomic変数型std::atomic<T>を利用すること。Consistency)をもつため、プログラマの期待通りに振る舞うことが保証される(→id:yohhoy:20141221)。等によるロック操作が必要。ノート:Objective-C/atomic属性プロパティは何の役にも立たないばかりかむしろ有害と考える。若干のメモリアクセス・オーバーヘッドに加え、マルチスレッド処理バグの潜在要因となり得るリスク因子である。