objective-c - @synchronizedvsロック/ロック解除

Question

私はObjective-Cを初めて使用します。いつ使うべきですか@synchronized、いつ使うべきlock/unlockですか？私のバックグラウンドは主にJavaです。Javaでは、明示的なロックを取得すると、より複雑で、広範囲で、柔軟な操作（リリース順序など）を実行できるのに対し、synchronizedキーワードを使用すると、ロックがブロック構造で使用されるようになります。また、取得方法とは逆の順序でリリースする必要があります。同じ理論的根拠がObjective-Cにも当てはまりますか？

Answer 1

多くの人は、任意の順序でのロック/ロック解除を機能ではなくバグと見なします。つまり、非常に簡単にデッドロックにつながります。

@synchonized()いずれにせよ、スコープの詳細を除けば、 、-lock/-unlock、またはその他のミューテックスの間にほとんど違いはありません。それらは高価で、壊れやすく、エラーが発生しやすく、多くの場合、それらを完全に正しくすると、とにかくシングルスレッドソリューションに似たパフォーマンスが得られます (ただし、スレッドの複雑さがあります)。

新しいホットネスはキューです。キューは、通常、ほとんどの呼び出しの原因となる「高速パス」操作にシステム呼び出しを必要としないという点で、はるかに軽量になる傾向があります。彼らはまた、意図をはるかに表現する傾向があります。

グランドセントラルディスパッチまたはNSOperationQueue具体的に。後者は、現在の OS リリースで前者に基づいて構築されています。GCD の API は低レベルになりがちですが、非常に強力で驚くほどシンプルです。 NSOperationQueueより高いレベルであり、依存関係などを直接表現できます。

Cocoa concurrency guideから始めることをお勧めします。

Answer 2

あなたは一般的に正しいです。 @synchronized特定のオブジェクトに「アタッチ」されたロックを取得します (ディレクティブで参照されるオブジェクト@synchronizedはロックである必要はありません)。Java と同様に、新しいブロックを定義し、ロックは最初に取得され、通常どおりブロックを離れるか、例外によって終了するかによって、終了時に解放されます。したがって、ご想像のとおり、ロックは取得と逆の順序で解放されます。