問題タブ [nslock]

私は iOS アプリを開発しており、同じ NSLock オブジェクトのロックを待機しているスレッドの数を知る必要があるという問題の解決策を実装する必要があります。

Java には、「このロックの取得を待機しているスレッドの推定数を返す」メソッド getQueueLength を備えたクラス ReentrantLock があります。

Objective-Cに似たようなものはありますか? 私は何かを見つけようとしましたが、何もありません。このメカニズムを自分で実装するには、NSLock をサブクラス化する必要がありますか?

非同期ブロックで関数を呼び出す共有操作を実行しようとしていますが、次の if ステートメントでは、ブロックで完了した値を取得して続行する必要があります。これは、詳細を強調する私のコードです。NSLock のことを聞いて使ってみましたが、うまくいきませんでした。何かロックをしているのかもしれません。ロックに詳しくありません。

特定の時点でアプリがフリーズするという奇妙な問題が発生しています。私はそれが私がどのように使用しているかに関係していると推測していますNSConditionLock。

私が使用するように与えられたライブラリがあります。これは一連の調査の質問で構成されていますが、回答を受け入れることなく最後の質問に直接競争するように機能するため、スレッドを一時停止してからの入力を受け入れる必要がありますユーザー。

以前に使用したことがないので、間違って実装している場合、誰かが助けてくれるでしょうか? 提供されたコードが不十分な場合はお知らせください。

編集:要するに、この Java スニペットに相当する Objc が必要です...

編集 2: Paul のリクエストによる ShowUI メソッド。

経験があるかもしれませんが、非スレッドセーフ変数へのアクセスは大きな頭痛の種です。iOS簡単な解決策の 1 つは、keyword を使用することです。これ @synchronizedによりNSLock、一意の 1 つのスレッドがデータにアクセスできるようになります。欠点は次のとおりです。

1. ロックが多すぎると、特にメイン スレッドによって呼び出された場合に、アプリのパフォーマンスが大幅に低下します。

2. ロジックが複雑になるとデッドロックが発生します。

上記の考慮事項に基づいて、シリアル キューを使用して処理することをお勧めします。各スレッド セーフの重要な操作はキューの最後に追加されます。これは優れたソリューションですが、問題は、すべてのアクセス インターフェイスを非同期スタイルで設計する必要があることです。次を参照してください。

このクラスを呼び出す人々は、このように設計することに消極的ではありません。この分野の経験がある方は、共有して一緒に議論してください。

Should i declare NSLock as atomic, or it's just a waste of time and the lock itself should be non atomic?

特定のリソースをロックするために使用することは知ってdispatch_barrier_asyncいますが、私の場合は、ディスク上のリソースではなく共有データ構造を変更しておらず、キュー全体をブロックしたくないため、良い候補ではありません。アクションには時間がかかる可能性があるため、指定されたキー。複数のスレッドから同時に同じファイルに (名前で) アクセスすることに関して、ファイル システムがどのように機能するかはわかりません。ドキュメントで明確な答えを見つけることができませんでした。「ファイル名」でロックしたいのですが、メソッド「tryLock(key)」がありません

何かのようなもの：

編集：

@synchronizedこれを行いますか？これは適切なユースケースですか？

UIKit アニメーションが終了するのを待たなければならない状況があり、完了ブロックを使用して関連するファイナライズ コードを実行しています。ここで、メイン スレッドから関数を 2 回呼び出すと、エラーが発生する競合状態が発生する可能性があることに気付きました。単純な @synchronized(self) ロックを使用できませんでしたが、NSLock を使用する別の回避策があります。これに対するよりエレガントな解決策があるかどうか疑問に思っていました。

これが使用されるコンテキストを示すために、UIAttachmentBehaviour (UIKit ダイナミクス) を介して多数のビューを相互に接続し、いくつかの物理的なアニメーションを実行します。ビューをスワイプすると、ビューが置き換えられ、アニメーションはビューがスライドイン/スライドアウトするように見えます (単純な翻訳)。私のソリューションでは、添付ファイルの動作を削除します。そうしないと、物理的な添付ファイルがスライド ビューに従います。これは、私が望んでいるものではありません。

問題のあるコードは次のようになります。

問題を手動でトリガーするのは難しいことに注意してください。ただし、コード スニペットをプログラムで呼び出すと、実行順序が若干異なります。アイデアを出すために、コード部分に A、B、C、D のタグを付けました。最初の実行行のトレースを 1A...1D と呼び、2 番目の呼び出しを 2A...2D と呼びましょう。通常の状況では、望ましい実行順序は次のようなものです。

ただし、handleGesture をプログラムで 2 回呼び出す場合の実行順序は次のとおりです。

私が思いついた回避策は次のようになります。

tryLock の代わりに lock を呼び出すと、コードがメイン スレッドで実行され、ブロックされるとアニメーションが終了しないため、デッドロックが発生することに注意してください。

つまり、handleGesture が呼び出されると、アニメーションが終了するまでロックされます。完了ブロックの間または後に関数が再度呼び出されると、ロックを取得しようとします。取得できない場合は、0.5 秒 (アニメーションの所要時間とほぼ同じ) 後に再試行します。

今、これは食事の哲学者の問題になる可能性があると感じています. 関数の先頭に @synchronized(self) を置けば問題は解決すると思ったのですが、アニメーション操作をメインスレッドにプッシュすると、関数はすぐに戻り、ロックはすぐに解除されます。

ここまで読んでくれてありがとう。

プログラミングの観点からは、コードの書き方が原因で、必ずしもこれを回避できるとは限りません。

基本的に、疑似コードで：

基本的に条件チェックは setFlag が終了する前に行われるため、チェック時に true になることはありません。didSetFlagFinishExecuting の行に沿って 2 番目のグローバル ブール値を追加しても、同じ問題が発生します。条件付きは他のものより前に発生します。while ループに入れたのですが、コーディングの仕方が原因で無限ループに陥ってしまいました。スレッドロック/GCD の経験がありません。私はそれを使用しないことを好みますが、必要に応じて使用します。助言がありますか？

編集:実際のコード

// viewDidLoad で

// ViewController の拡張として

したがって、ここで最後に Global.loggedIn を出力すると、true になります。これは時間内に終了するだけではありません。return 関数にしても、なんらかの理由で viewDidLoad の条件が false として読み取られ、THEN "hello" が出力されます。