Objective-C の atomicity について調べてみる

まずは、プロパティの原子性を atomic や nonatomic で制御する方法です。

プロパティの実装を @synthesize で自動実装することで、Objective-C が想定している原子性の制御を確認できます。

結果はこのように、atomic で制御されたプロパティだけが、値を矛盾させることなく完了しました。

実行にかかった時間は 27.96 秒です。

これが原子性を保護する (atomic) か、保護しない (nonatomic) かの違いということですね。

処理速度も興味深いところで、50,000 回の表示ループの中で、原子性を保つ atomic プロパティの書き換え回数よりも nonnatomic プロパティの書き換え回数の方が 4.4 倍以上も高速でした。

次に気になったのが、プロパティを独自実装した時の atomic や nonatomic の挙動です。

@sinthesize で自動実装したときに atomic にはロックが自動で補われるというのなら、@synthesize しなかった場合は、自分でロックを実装しなければいけないかどうかが気になります。

そこで、プロパティ宣言は 01 と同じまま、実装だけを @synthesize に頼らずに実装してみることにしました。

この時、あえて @sychronized (self) は使用しないで、セッターでは純粋にインスタンス変数に値を代入し、ゲッターではインスタンス変数の値を return するだけの実装にします。

結果は atomic も nonatomic も同じくらいの実行回数になりました。

実行時間は 32.40 秒です。

そして、期待通りと言いますか、今回の場合だと atomic の場合でも値に矛盾が発生することがありました。

このことから、プロパティの属性として atomic を指定していたとしても、@synthesize で自動実装しない限りは、ロック処理が前後につけられることはないようでした。

つまり、たとえば「スレッドセーフだけどロックは要らない」ような場面があるとしたら、属性に atomic を付けて明示した上で、プロパティを自分で実装すればいいことになります。

逆に、自分で atomic プロパティを実装するときには、自分でロックを実装しなければいけません。

■ プロパティへのアクセスは意外と負荷がかかる？

ところで、今回はどのケースでもロックが実装されなかったようなので、どれも同じくらいの速度になってもよさそうですけど、書き込みがインスタンス変数への直接代入というケースで、実行回数に大きな伸びが見られました。

その差は 1.9 倍くらいと、なかなかの具合です。

つまり、プロパティを通してインスタンス変数に書き込むのと、インスタンス変数に値を直接書き込むのとでは、ロックに関係なくこれくらいの速度差が生まれるということなのかもしれません。

頻繁な繰り返し処理で、速度を出したいところでは、インスタンス変数に直接アクセスするかどうかもカギになりそうですね。

それなら、プロパティが扱うインスタンス変数に直接値を読み書きしたらどうなるでしょう。

プロパティは @synthesize で自動実装します。値の確認はプロパティを介して行いますが、値の読み書きを繰り返すスレッドでは、インスタンス変数 (ivar) を直接読み書きします。

結果は、大幅な速度アップになったようです。

実行にかかった時間は 34.43 秒と、それほど変わらなかったのですけど、実行できた回数が nonatomic のときでテスト 01 と比べて 1.8 倍くらい伸びています。

もっとも、読み書き用のスレッドでインスタンス変数を直接操作しているため、別のスレッドからいくら atomic 指定のプロパティを介してアクセスしても値は壊れてしまっています。

また、インスタンス変数を直接アクセスしてしまうと、派生クラスを作るときに融通が利きにくくなったりもするので、使いどころは注意しないといけないですけど、nonatomic で大丈夫なところで速度を出したい場面などでは、上手に使いたいところですね。

ところで、本当に @synchronized (self) と atomic + @synthesize とが、関係ないことを確認してみます。

プロパティは読み取り専用で定義して、ゲッターだけを @synthesize 任せの atomic で制御します。プロパティのセッターは、別メソッドとして実装し @synchronized (self) を使って排他制御を行います。

atomic + @synthesize のロックと @synchronized (self) とが別ものであるなら、原子性が保てないはずです。

結果は、atomic 指定のプロパティでも、値に矛盾が見られました。

やはり atomic を @synthesize でロックしても、@synchronized (self) でそれをブロックすることはできないようです。

このように、atomic を @synthesize で実装した時に @synchronized (self) によるロックが自動的にされるという情報を鵜呑みにしていると、原子性は保てていないわ、速度は遅いわで、最悪の状態になることが判りました。

つまり自分は、最悪のコードを書いていた訳ですね。

ところで、今回ブロックに @synchronized (self) を使用しました。

今回は atomic のロックと @synchronized (self) と、ちぐはぐなロックで効果がなかったわけですけど、それにしても atomic テストで実行できた読み書き回数が、これまでよりも妙に少ないことが気になります。

ちなみに、実行にかかった時間は 28.59 秒でした。こちらはそれほど変わりませんね。

そこで、全ての atomic 制御を @synthesize 任せではなく、独自に実装してみることにします。

ロックは @synchronized (self) を使って、atomic 指定のプロパティの、ゲッターとセッターの入り口から出口までをブロックします。

実に nonatomic が atomic の 116.5 倍も高速という結果になりました。

テストにかかる実行時間は 27.32 秒と、@synthesize のときとそれほど変わりませんでした。そして、今回の @synchronized (self) でも @synthesize のときのように、値の矛盾を起こさないようにロックすることはできました。

何度か実行してみてもこのような感じの開きになるので、再確認にはなりますけど atomic を @synthesize して自動実装されたときのロックが @synchronized (self) ではないことが想像できます。

ここから、出来る限り @synchronized (self) による自前の排他制御ではなく、@synthesize が生成するロックを使う工夫をした方がいいと思われます。

それなら、もう一つのロックの方法である NSLock を使う場合はどうでしょう。

インスタンス変数に 1 つの NSLock を用意して、それを 使って atomic 指定のプロパティのゲッターとセッターの入り口から出口までをブロックします。

@synchronized で self を指定したのと同じように、同じ 1 つのインスタンス変数をつかって、合計 3 箇所をロックします。

結果は、@synchronized (self) を使った場合と比べてわずかに高速化したかどうか、といった感じのようです。

検証が終わるまでの時間が 1.5 秒ほど伸びたものの、atomic のときに計算した数が 1.8 倍に増加しています。逆に nonatomic の実行回数が 0.9 倍に減少しましたけど、他のスレッドの効率が良くなった分、それに足を引っ張られたのかもしれません。

ともあれ、クラス全体の整合性をとりたい場合は @synchronized (self) を使うより、NSLock を使った方が動作が速そうな気がします。

ただ、後で知ったのですけど @synchronized (self) が採用するロック方式は NSRecursiveLock と同じ再帰的ロックになるようです。これについてはまた後で検証することにします。

ところで、プロパティ単体の原子性の保護であれば、何も 2 つのプロパティで同じ NSLock を使う必要はないはずです。

もしかして @synthesize で実装する方が圧倒的に速いのは、そういったロックの仕方の違いなのかもしれません。

そこで、atomic なプロパティそれぞれで使用する NSLock インスタンスを用意して、それぞれを独立してロックさせてみることにしました。

試してみると、1 秒あたりの実行回数としては、全体でひとつの NSLock を使った場合と比べて atomic で 4.0 倍と、大幅な改善がみられました。

ただ、今回とても気になったのが、全体としての実行速度の遅さです。

実行が終わるのに 104.39 秒、全体でひとつの NSLock を使ったときの 29.04 秒と比べて 3.5 倍も遅くなってしまいました。

同じ 50,000 回のチェックが終わるまでの時間が長くなったということは、チェック時にプロパティを読み込む時の、ロックを取得するための待ち時間が増えたということになるのでしょうか…。

それとも、もしかすると各スレッドの処理能力が向上したため、その分 CPU が忙しくなって、50,000 回の監視処理を終えるまでの時間が長くなってしまったのかもしれません。

プロパティごとに NSLock ではなく NSObject を用意して、それを @synchronized でブロックした場合はどうなるでしょう。

今回は、各プロパティ用のロック用のインスタンスとして NSLock の代わりに NSObject を生成して、それを @synchronized の引数に指定します。

結果は、実行終了までにかかった時間は 98.39 秒だったので、それほど変わらない感じです。

ただ、その間に実行できた回数が、atomic で 0.5 倍に減少しています。nonatomic のときの実行回数に大きな差は見られなかったので、もしかすると @synchronized よりも NSLock の方が高速に動作するのかもしれないです。

ところで、あまりにも実行速度の遅さが目立ったので、試しとして読み書きのループのところでわずかな時間、スレッドをスリープさせるとどうなるか見てみます。

まずは NSLock を使ってプロパティをそれぞれロックする場合です。

結果は、終了するまでの時間は 11.52 秒になりました。

それだけ見れば 8.5 倍ほど速くなっていますけど、1 秒間に実行できた回数も大幅に減少しています。ループの合間にスリープを入れているのだから、実行回数が減少してくれて当然ですね。

それでいて終了までの時間が短くなっているのは、スリープによって負荷が軽減された分、50,000 回の監視処理が速く終わったのだと思われます。

スリープを入れると余力がでるなら、この時の方が NSLock と @synchronized の速度差が確認しやすいかもしれません。

そこで、先ほどの NSLock の部分を @synchronized に換えてチェックしてみます。

結果は、終了までの時間は 13.19 秒で、NSLock でブロックした場合に比べて 1.1 倍ほど時間がかかっています。

1 秒間に実行できた回数も NSLock のときと比べて 1 割ほど減少しているので、やはり @synchronized の方が NSLock よりも若干遅くなると思っていいのかもしれません。

ロックにはもう一つ、セマフォというものが利用できるので、これを使ってみたいと思います。

セマフォは、それぞれのプロパティ毎に dispatch_semaphore_create(1) で作成して、dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER) で待つ形で実装してみます。

それでは、まずは読み書きスレッドの合間にスリープを挟まない場合を試してみます。

実行が完了するまでにかかった時間は、36.59 秒になりました。

これまで、@synchrnonized や NSLock を使ってプロパティを個別にブロックしたときの実行時間が、それぞれ 104.39 秒と 98.39 秒だったので、それと比べて随分の短縮が図れたようです。

そして 1 秒あたりの実行回数は、それらを大きく上回る結果になりました。NSLock とは 2.2 倍、@synchronized とは 3.9 倍という結果です。

@synthesize による自動実装と比べても 1.1 倍ほど処理回数が増えたので、自動実装と同等の性能を出したい場合にはこれがいいかもしれません。

もうひとつ、セマフォでロックして、読み書きのループで毎回スレッドをスリープさせるコードも試してみます。

結果は、処理時間 12.92 秒でした。

実行時間も実行回数も、NSLock や @synchronized とスリープを併用した場合と比べてほとんど変わりない様子です。

このことから、待ち時間なしの繰り返し処理みたいな場合でなければ、どれを使ってもそれほど大きな影響はないかもしれません。

逆に、局所的な for ループなどで、その中で atomic プロパティに頻繁にアクセスする場合には、@synthesize による自動実装かセマフォによるロックが活きてくるかもしれないですね。

ついでに、各プロパティで共通のセマフォを使ってロックする方法で試してみます。

セマフォは、ひとつだけ dispatch_semaphore_create(1) で作成して、dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER) で待つ形で実装してみます。

今回は、読み書きループにはスリープを挟みません。

実行にかかった時間は 33.25 秒でした。

ロックの種類が違うだけで、期待される効果は @synchronized (self) と同じと思うのですけど、実行時間が 6 秒ほど長くなったものの、1 秒あたりの実行回数が 9.3 倍向上しました。

セマフォはインスタンス変数に持たせているので、これなら @synthesize の自動実装と違って、メソッドを含めた複数個所の整合性を保つ用途にも使えそうですね。

実行回数はさすがに、プロパティを個別に保護する @synthesize による自動実行には及びませんけど、全体を保護できるロックでこれくらいの数値が出るのは嬉しいところです。

今回の実験は 64 ビット変数の値が壊れることがあるということを知ったことがきっかけなので、その long long の原子性について検証してみたいと思います。

テスト環境は 64 ビット CPU 搭載の Mac mini Early 2009 ですけど、そこの iPhone 6.0 シミュレーター上でテストしているので、もしかするとデータに矛盾が出てきてくれるかもしれません。

実装としては、偶数回目の代入のときには -1 を、奇数回目の代入のときには 1 を代入して、それらの処理とは別に別スレッドから値を読み込んで、それが 1 や -1 以外になることが無いかを監視します。

このように、64 ビットの Mac でも iPhone 6.0 シミュレーター上であれば、プロパティを介して nonatomic な値を読み書きした場合だけ、矛盾を生じることが解りました。

続いて、セッターは @synthesize で保護するけれど、ゲッターはロックなしで実装するという、少しちぐはぐな実装を試してみます。

具体的な実装としては、プロパティをいったん atomic で定義して @synthesize で実装したクラスから派生クラスを作成して、ゲッターだけをオーバーライドしてインスタンス変数をそのまま返す形をとってみます。

検証してみると、期待通り atomic プロパティが矛盾するようになりました。

それなら 32 ビットの long 型ならどうなるかと思って検証してみました。

今どきのものであれば 32 ビットを 1 回で読み書きできそうなものなので、これなら nonatomic であっても矛盾しないかもしれません。

結果は atomic も nonatomic も矛盾なしです。

現在の Objective-C の long 型は 32 ビットなので、このサイズなら複数スレッドからの同時アクセスでも影響を受けないのかもしれませんね。

そしてもう一つ、面白いことがでてきました。

long を対象とした atomic での操作と nonatomic での操作では、1 秒間に実行できた回数に、大きな差が見られなくなりました。

何度か実行してみても同じような数値だったので、もしかするとコンパイラが、今回の long 型の場合には原子性を確保する処理は必要ないとしてくれているのかもしれないですね。

もしそうだとすれば、この変数は何ビットだから nonatomic 指定にしても安全で速いかもとかいった配慮は不要で、原子性を保ちたければ atomic にするという意識でコーディングすることができそうです。

ここからは、値が Objective-C インスタンスである場合を見てみます。

処理としては構造体での検証のときと同じですけど、構造体ではなくて id 型でインスタンスを持つ場合です。今回はあえて構造体と似せるために、インスタンス変数を @public で定義して、直接参照できるようにしてみます。

プロパティのオーナーシップは、まずは strong で試してみます。

結果は、思ったよりも正しく動くことが多かったですけど、それでも何度も試してみると値が矛盾する場合があることが確認できました。

クラスインスタンスの場合は atomic 指定の場合であっても、インスタンスが持つ値が矛盾することがあります。

これは、あくまでもクラスインスタンスではポインタだけが保護されるので、そのインスタンスが持つ変数に値を代入するところは保護の対象にならないためです。

また、ごく稀に EXC_BAD__ACCESS で落ちることもありました。

これは何故か atomic でも発生しました。プロパティの取得だけなら atomic 指定なので問題ないはずなのですけど、どういう訳か "error: can't allocate region" というエラーで強制終了されてしまいます。

もしかすると今回は、クラスインスタンス 1 つを使いまわしていることと、インスタンス変数を直接アクセスしていることも、何か関係するのかもしれません。

そんな感じで、期待通りの動作が確認できないものの、それとは別の、プロパティが Objective-C クラスで strong 指定のときの atomic キーワードで保護される内容についてみて行きます。

bjective-C クラスのインスタンスの場合、原子性が保たれるのはあくまでも受け渡しをするポインターであって、それが持つ値については関与しないところに注意が必要です。

■ atomic, strong 時のゲッターは retain & autorelease で保護される

まず atomic,　strong なプロパティのゲッターを呼び出してみると、retain & autorelease が呼ばれます。

これはつまり、retain して参照先のオートリリースプールに入れるまでの処理を不可分で実行しています。これによって、参照先が確実にインスタンスを確保することができます。

■ nonatomic, strong 時のゲッターは retain & autorelease されない

nonatomic なプロパティでは、ゲッターで取得したときには何も呼ばれませんでした。

■ strong で生成されるセッターについて

セッターは、retain プロパティの場合は atomic でも nonatomic でも、代入時にインスタンスが retain されます。

ただし、既に代入されているインスタンスをセットしようとした場合は何もしないようでした。

■ strong インスタンスの保護はまた別の問題

あくまでも @synthesize による実装では、保護されるのはクラスインスタンスのポインターだけなので、そのクラスが扱うプロパティについては実装先で保護する必要があります。

また、プロパティやメソッドを操作したときに、クラス全体としての整合性（一貫性）を保証するには NSLock や @synchronized (self) などといった、ブロックの仕組みが必要になってきます。

ついでにちょっと、@synthesize ではなく @synchronized (self) で保護した場合の速度の違いを見ておきます。

先ほどのテストのセッターとゲッターをオーバーライドして、@synchronized (self) でロックをするように実装します。

結果は、@synthesize による自動実装のときよりも 2 倍ほど遅くなりました。

やはりクラスインスタンスの場合でも、@synchronized (self) の方が速度は遅くなるようです。

また、こちらのテストも相変わらず、atomic でも nonatomic でも、稀に EXC_BAD_ACCESS (error: can't allocate region) で落ちる様子でした。

落ちる個所も、クラスインスタンスのポインターをインスタンス変数から読み取って return する行で発生したりすることがあったので、プロパティの atomic だけでは保護できない何かがあるのか、もっと何か根本的なバグがあるのかもしれません。

値として使用しているクラスのインスタンス変数を同時にアクセスしているところも気になるところではありますけれど。

先ほどのテストが予期しないエラーで落ちてしまうことがあるのが気にかかりつつ、ともあれ、スレッドセーフを考える上で、もう一つ意識しなければいけないところがあります。

プロパティの atomic が保護するのはあくまでもポインターなので、その先を同時に編集してしまうと、せっかく retain & autorelease でインスタンスの生存が保護されても、とたんに矛盾した結果になってしまいます。

そこから保護するには、プログラマーの側で、取得したポインターをローカル変数に複製してから編集して、編集が終わったインスタンスのポインターで、プロパティのポインターを置き換えるという作業が必要です。

つまり、同時アクセスを考慮する場合は、先ほどのテストのようなインスタンスを直接書き換える方法ではなく、インスタンスをコピーして書き換える方法の方が、きっと適切と言えるでしょう。

そういうことで、今度はインスタンスをコピーしてから編集する方法でテストしてみます。

今度は、自分のスレッドの中で自分だけで値を編集するので、値も矛盾することがなくなりました。

そしてもうひとつ重要なこととして、nonatomic の方はあっというまに EXC_BAD_ACCESS で落ちてしまいました。

今回の EXC_BAD_ACCESS は解放済みのインスタンス (deallocated instance) に触れてしまったために発生するもので、これはきっと、監視スレッドが nonatomic プロパティ経由でインスタンスを参照した直後に、読み書きスレッドがそのインスタンスを使い終わってしまったために起こっています。

このような、別のスレッドでまだ使用するインスタンスを解放してしまうという事態を防ぐ工夫が、@synthesize で実装した atomic プロパティには生成されます。

先ほども触れましたが、具体的にはゲッターで、retain & autorelease をロックの中で実行することで、インスタンスの解放を防いでいます。

先ほどのテストとほとんど同じですが、プロパティを @synthesize による自動実装をした場合についても、参考として調べてみます。

やはり処理できる回数は @synthesize の方が多くなりますね。

それ以外の様子については、@synchronized (self) を使って実装していた場合と同じです。

だいたい様子が見えてきましたが、ARC 環境で実行していると retain や release などが自動で実行されるため、動きが捉えにくいところがありました。

そこで、Non-ARC でコーディングした同等のクラスでも実験してみます。

結果は、ARC 環境のときと違って、nonatomic の場合でもあっという間に強制終了されるようなことはなくなりました。

そうそう落ちない感じですけど、だからといって安全になったわけではないので注意が必要です。

ARC は細やかにメモリ管理をしてくれるので、タイミングがシビアになるのかもしれないですね。

ARC に対応させたらよく落ちるようになったという場合は、プロパティの atomicity が影響してたりするかもしれないです。

続いて、プロパティで指定できる copy についても調べてみます。

プロパティの属性が copy の場合も、retain のときとほとんど同じです。

今回も読み書きのループでインスタンスを copy しているので、メモリ管理が頻繁になる都合、nonatomic の場合はすぐに強制終了されてしまいます。

今回は新たに copy でのプロパティ操作を見てみたので、そのときの Objective-C インスタンスの保護のされ方についても整理してみます。

■ atomic, copy 時のゲッターは retain & autorelease で保護される

まず atomic,　copy なプロパティのゲッターも、strong のときと同様、retain & autorelease が呼ばれます。ゲッターのときはあくまでも retain で、copy にはなりません。

このようにして、参照先が確実にインスタンスを確保できるように配慮してくれます。

■ nonatomic, copy 時のゲッターは retain & autorelease されない

nonatomic なプロパティでも、strong と同様、ゲッターで取得したときには何も呼ばれませんでした。

■ copy で生成されるセッターについて

セッターは、retain プロパティの場合は atomic でも nonatomic でも、代入時にインスタンスが copy されます。

strong のでは既に代入済みのインスタンスをセッターに渡すと無視されましたが、copy の場合は渡されたインスタンスの copy をとって設定する処理が必ず行われます。

■ copy のインスタンスの保護はまた別の問題

copy でも、あくまでも @synthesize による実装では、保護されるのはクラスインスタンスのポインターだけなので、そのクラスが扱うプロパティについては実装先で保護する必要があります。

ただ、copy に対応しているクラスの場合、copy メソッドでインスタンスの複製を取ることができるので、プロパティからインスタンスを取得したら copy で複製してから編集して、編集後にセッターに複製済みのクラスを渡すということを徹底することで、インスタンスの内容が矛盾するような状況を防げます。

このあたりの操作は、構造体が atomic で保護される様子と似ていますね。

続いて weak の場合を見てみます。

weak には、格納時にはインスタンスは retain されませんが、どこかでそのインスタンスが解放されると、格納されているポインターが nil になるという性質があります。

マルチスレッドの場合でなくても、どこかで解放されてしまった後にそのインスタンスを使ってしまっても、不正アクセスで強制終了されるようなことがないので、delegate での使用にとても向いています。

実験してみると、さすが weak の威力は絶大な様子です。

atomic でも nonatomic でも、タイミングによって nil が取得できますけど、これは、保持していたインスタンスが既に解放されていたためであって、weak としては期待通りです。

weak プロパティ自体は retain しないため、このように外部のインスタンス管理に依存するのですが、それに振り回されることなく捌ける様は流石でした。

今回は新たに weak でのプロパティ操作を見てみたので、そのときの Objective-C インスタンスの保護のされ方についても整理してみます。

プロパティの属性が weak の場合は、retain や copy とはまた違った動きを見せました。

■ weak で生成されるセッターについて

セッターは retain も copy もしませんけど、裏方ではきっと weak のための根回しがされているのでしょう。

■ weak 時のゲッターは autorelease だけされる様子

そして不思議なのがゲッターです。ARC のせいもあって確かなことが言いにくいのですけど、ゲッターの中では retain されず、なぜか autorelease だけが実行される様子です。

ここに限らず __weak 指定の変数にインスタンスを代入したときにも autorelease だけが呼ばれる挙動を示すようなので、もしかすると weak のシステム内部のどこかで retain されていたりするのかもしれないですね。

でももしそうだとすると、今回のテストで使った派生クラスの retain メソッドが呼ばれていないので、retain で独自の実装をしている場合は weak 環境で動作不良を起こすこともあるかもしれません。

そんな感じで、いまいちわかっていませんが、atomic でも nonatomic でも、weak のゲッターはこのような動きになるようです。

weak での動作で少しわからないところがあったので、ARC がなかったころの retain しない assign プロパティでの動作を見てみることにします。

retain などの制御が ARC の影響を受けないように　Non-ARC で実装してみます。

結果、atomic でも nonatomic でも、解放済みのインスタンスを取得できてしまうことがありました。

atomic でもそうなる理由は、assign が保持するインスタンスは retain されないためで、それだけでなく、インスタンスを取得するときも retain & autorelease されないため、使用中にインスタンスが解放されないことがあるためです。

実行回数が atomic も nonatomic もほぼ同じになるあたり、どちらも完全に 32 ビット（ブロック不要）のアドレスを読み書きするだけという様子がうかがえますね。

ちなみに、Non-ARC での assign の場合、クラスインスタンスのプロパティやメソッドにアクセスしなければ、直ちにプログラムが強制終了されることはありませんでした。

これは、ARC が気を利かせて retain や release をしないせいで、ポインタだけ貰ってアクセスしないで済んでいるためのようです。

Objective-C クラスのインスタンス変数を @public で定義しておくと、解放済みのインスタンスからもそのインスタンス変数をエラーなく参照出来たりするみたいで、dealloc で解放済みかどうかのフラグを設定しておけば、解放済みかを判定できるという裏技的なこともできるようでした。

解放済みインスタンスのインスタンス変数をアクセスできるかどうかは未定義だと思うので、やらない方がいいでしょうけど。

さて、assign 指定での Objective-C インスタンスの保護のされ方について整理すると、次のような感じです。

■ assign で生成されるセッターについて

assign のセッターでは retain も copy もしません。assign が示す通りの実装です。

■ assign 時のゲッターも何もしない

そしてゲッターも、assign の場合は何もしません。

何もせずに、保持しているインスタンスのアドレスだけを素直に return します。

ただ、これって Objective-C のインスタンスを保護していると言えるのでしょうか。

atomic でもこの動作なのですけど、この実装ではロックの中で retain & autorelease をしてくれないので、明らかにタイミングによってはインスタンスが解放されてしまいます。

いつどこで解放されてもおかしくないインスタンスを扱うわけですから、それでいいのかもしれないですけど。

そんな面からも、同時アクセスから保護するような場合には、assign は向いていない様子です。

マルチスレッドで retain しないでインスタンスを管理するなら weak を使用するのが良さそうでした。

念のため、ARC 環境での assign の動きについても見てみます。

結果は、さんざんなものでした。

ARC が気を利かせて即座に retain するものだから、atomic も nonatomic も即座に強制終了されてしまいます。

プロパティで扱うインスタンスも、assign のため、どこかで retain されることもなく、ARC があっという間に解放してくれるため、複数スレッドからのアクセスにすぐに潰れてしまう感じでした。

もちろん、今回のテストと相性がとても悪いだけで、実装方法を工夫すれば実用もできるでしょうけど、ARC ならどんな場面でも weak を使った方が良さそうに思えました。

weak プロパティの実装を @synthesize に頼らない場合に、どういう風に実装したらより近くなるのだろうと思って調べたときの実装です。

検証 23 と比べて実行回数が下がるのはさておき、独自にプロパティを実装してみると、ゲッターで例えば次のように内部で変数に一回受ける実装と @synthesize による方法とでは、動作にわずかな違いが見られました。

このようにすると、ローカル変数 result に格納した時に 1 回、weak の作用と思われる autorelease が呼ばれた後、戻り値を変数で受けたもう 1 回、autorelease が呼ばれるような感じでした。

@synthesize で自動実装した場合には、一連の動作の中で weak のものと思われる autorelease の呼び出しが 1 度だけになります。

内部で受ける変数を __strong にしてみたり __unsafe_unretained にしてみても、@synthesize とは僅かに違う動作を見せるようです。

これを自動実装のときに似せようとした場合、次のように @try-@catch による実装に行き着きました。

このように、変数で受けずにインスタンス変数を直接 return するのが、@synthesize の実装に近い動きをするようです。

return した後にロックが解除されるように、@try-@finally を使って、スコープを抜けたタイミングで unlock するようにしています。

何もわざわざここまで @synthesize の挙動に似せる必要はないでしょうけど、参考として調べてみたくなったのでやってみました。

ロック方法に pthread mutex というのがあるのを知り、それを使ったロックも試してみることにしました。

今回は、構造体の値に対して、プロパティで共通の mutex を使用します。mutex の種類は PTHREAD_MUTEX_NORMAL を指定しました。

@synchronized (self) と比較する場合は PTHREAD_MUTEX_RECURSIVE の方が適切のようですけど、この時はその違いが判っていなかったので PTHREAD_MUTEX_NORMAL での検証です。

mutex を pthread_mutex_init(_mutex, NULL) で実装します。

そして、読み書きループにはスリープを挟みません。

実行にかかった時間は 25.47 秒でした。

これまでの検証と比べると、dispatch_semaphore の方が 4.1 倍も速くなりました。逆に @synchronized (self) と比べると 0.4 倍と最も遅く、NSLock と比べると 0.7 倍の速度になりました。

これらはプロパティ間で共通のロックを使用しているのでより遅くなっているとは思いますが、@synthesize による実装の方が 6.1 倍速いところを見ても、可能であれば @synthesize に任せてしまうのがいちばん良さそうです。

@synchronized 以外のロックを使う場合、例外が想定される場面では @try-@finally で括る必要が出てきそうです。

その時にどれくらいの速度低下が見られる可能性があるか、先ほどの pthread mutex を @try-@catch を使うプログラムに、調べてみることにします。

結果は、実行にかかった時間は 28.30 秒。

1 秒間に実行できた回数は、@try-@finally を使わなかった場合に比べて 0.8 倍程度に低下しています。

これくらいの速度低下なら、必要なところでは積極的に @try を使い、必要ないところを見極めて @try を使わない、そんな感じの実装で問題なさそうな気がしました。

最後になって、Objective-C クラスとして提供されるロックには NSLock のほかにも NSRecursiveLock と NSConditionLock の 2 つが存在していることを知りました。

そのうちの NSRecursiveLock は、pthread mutex の PTHREAD_MUTEX_RECURSIVE と同等の再帰的ロックであるということで、ようやくロックには細やかな性質の違いが存在することに気が付きました。

どうやら @synchronized もこの再帰的ロックに該当するようです。

細かいお話は ミューテックスによる排他制御を行う ですることにして、ここではこの NSRecursiveLock の速度について検証しておくことにします。

実行にかかった時間は 28.42 秒と、NSLock のときとほとんど一緒になりました。

1 秒間に実行できた回数は 0.9 倍弱に低下しています。一般に PTHREAD_MUTEX_DEFAULT (FAST) の方が PTHREAD_MUTEX_RECURSIVE よりも処理が軽量になるそうなので、その影響が出ているのでしょう。

ともあれこの程度であれば、用途に合わせて NSLock か NSRecursiveLock かを選んで使って行けそうです。