順序付けられたサーバーカウンタと同期させます
上記の例は、構築したい順序付けられたサーバーカウンターです。 ボタンをクリックすると:
- 非同期要求がサーバーに送信されます
- サーバーは内部カウンタをインクリメントします
- サーバーは現在のカウンタ値を返します
- クライアント（私たちのwebページ）
受信したときに数字の順序が保持されることが重要です。 では、要求の順序をどのように同期させることができますか？ 私たちは、ネットワーク要求が非同期であることを知っています。 最初の要求が2番目の要求よりも到着するまでに時間がかかること、または2番目の要求が3番目の要求よりも時間がかかることなどが完全に可 リクエストのこの順序外の到着は、我々のアプリケーションのための問題になります。
“同期なし”アプローチ
同期構造を持たないこのアプリケーションを開発するとどうなりますか？ ここでは、同期のないこのアプリケーションのシミュレーションの実装例を示します。
サーバーはprocessCommmand()でシミュレートされ、ネットワーク遅延はserverDelay()でシミュレートされます。 同期メカニズムがないため、”Click me”ボタンがクリックされると、新しい要求がすぐに発生します。
これはこの実装の結果です。
ええとああ—数字は、予想通り、順不同で表示されている、と私たちは順番に数字を表示するために私たちのアプリケーションを作ることができませんで
Mutexで順不同の問題を克服する
問題は、ネットワーク要求が順不同であることですが、アプリケーションはそれらを順不同にしたいと考えています。 これを解決する1つの方法は、Mutexロックを使用して、一度に1つの要求のみを処理できるようにし、他の要求が順番になるまでブロックすることです。
Mutexの実装は次のとおりです。
Mutex APIの使用フローは次のとおりです:
- 23行目:
clientLockを取得する要求が開始されます。 このリクエストは、他の誰かがすでにロックを取得していて、まだロックを解放していない場合にブロックされます - 行33:サーバーが応答してトーストを表示した後、クライアントロックが解放されます。 これにより、他のボタンクリックイベントがロックのために競合し、サーバーネットワーク要求を開始することができます！
このロック機構は、一度に一つのボタンイベントだけが処理され、他のボタンイベントをブロックしてキューに入れることを保証します。 これで、最初に示した元の例の意図された順序付きの実装を達成しました！
表示されるトーストの数を制限する
いくつかのトーストが一度に画面をあふれさせることが好きではない場合はどうなりますか？ ロジックを拡張して、一度に表示されるトーストの数を制限することができます。 ここでの同期構造はセマフォになります！
SempahoreをMutexのように考えてくださいが、複数の非同期要求が一度にコードを実行できるようにすることができます。 あなたも、最大数を設定することができます！
ミューテックスとセマフォを使用して、画面上のトーストの数を一度に2に制限することができました。
そして、上記の例に関連付けられたコードは次のとおりです
6行目
Sempahore構造体は値2で初期化されており、最大2つのトーストのみが時間を表示できることを指定しています。
26-31行目
セマフォロジックは、トーストを表示したいときに役立ちます。 私たちはSempahoreを取得しようとします。 成功した場合は、Toastオブジェクトを作成し、ToastのreleaseSemaphore()関数にcompleteCallbackを渡します。 このコールバックは、toastが終了したときに呼び出されます。
