iPhone用のマルチスレッドアプリケーションを作成しています。NSLockを使用して、ファイルからサウンドを読み込むなどの一部の操作がアトミックな動作をするようにしています。アプリケーションのさまざまな部分からロックを取得するのを簡単にするため、NSStringに名前を渡すだけでロックをロックおよびロック解除できるクラスを作成しました。そのようなロックが存在しない場合は、そのロックが作成され、将来保存されます。 私はそれをテストしたところ、正常に動作しているようです（NSLockオブジェクトへのアクセスを提供し、動作を変更しないため）。NSLock "controller"クラス
私の質問は：そういうクラスを持っているのは大丈夫ですか、あるいはロックの概念に誤解がありますか？
これはかなり重いです。デザインを単純化できないのは本当ですか？ （GCDが気に入っています）ほとんどのiOSアプリケーションはマルチスレッドのものですが、IMHOのように、あなたが書いたようなロックヘルパーを見るのはまれです。 KISS principleが輝く場所があれば、それはマルチスレッドだと確信しています。
@synchronized is slowを避けてください。 + initializeにロックを割り当てて、代わりにそれを使用してください。しかし、私はクラスメソッドを使うのではなく、シングルトンのために行くつもりですが、多かれ少なかれ味の問題です。
あなたのアプローチの主な欠点は、別のロックを取得するためにロックをロックする必要があることです。非常にマルチスレッドのアプリケーションでは、スレッドがすべて異なるロックにアクセスしたい場合でも、このメタロック（現在の@synchronized）はパフォーマンスのボトルネックになる可能性があります。
ありがとう、私はGCDを調べます。上記はちょうど私の頭に最初に来たものです。私が扱っている主な問題は、ユーザーが再生ボタンを押すと、別のスレッドでファイルからサウンドを読み込み始めますが、ユーザーがすぐに停止ボタンを押すと、サウンドがまだ読み込まれているので、このメッセージは無駄になります。最終的にロードされると、それは再生を開始し、これは既に必要ではありません。私はすべての関連メソッドを同じスレッドで開始しようとしましたが、いくつかの問題がありました。 KISSは素晴らしいですが、たまにしか知りませんが、あなたがやっているのは簡単かどうかです:)何らかの理由で、このコードは私にとっては単純です。 – Least
詳細は分かりませんが、ディスパッチキューは、あなたが記述したものとよく似ています。 （あなたはただ一つのシリアルキューにすべてのコントロールメッセージを送ります。それは、オーディオがロードされる前にストップイベントが来ないことを確かにします）。私にとっては、KISSの原理から出発するという兆候は、クラスメソッド、ヘルパー"マネージャー"オブジェクトと複数のロック。 YMMV。 – zoul