/* Page prose (ja) */
"WrappingUp" = "# まとめ\n\nこの二つのツールは二つの異なる問いに答えます。そして自分がどちらを問うているかを知ることが、闘いの大部分です。グループは「このバッチ全体はいつ終わるか」を問い、セマフォは「一度にいくつ実行してよいか」を問います。どちらも入念な帳簿付けには報いますが、ずさんさにはハング、クラッシュ、デッドロックで罰を与えます。下のバランスのルールを手元に置いておきましょう。\n\n* **`DispatchGroup`** は一群のタスクを追跡し、それらがすべて終わったときに発火します。**`DispatchSemaphore`** は、一度にリソースに触れる数を制限します。\n* 二つは**組み合わさります**。セマフォで一度に実行される数を抑え、グループでバッチ全体がいつ終わったかを知る、まさにエスプレッソの例が使ったペアです。\n* `notify(queue:)` はグループが空になったときにコールバックを実行し、**決してブロックしません**。これを優先しましょう。`wait()` は呼び出したスレッドをブロックするので、メインスレッドから遠ざけましょう。\n* **落とし穴:** 不均衡な `enter`/`leave` は、**ハング**する（leave が少なすぎる）か、**クラッシュ**する（多すぎる）かのどちらかです。対応する `signal()` のない `wait()` は、その後ろにいる全員をデッドロックさせます。直後に置く `defer { group.leave() }` / `defer { sem.signal() }` が安全なパターンです。\n* **落とし穴:** セマフォでブロックされたタスクを何十個もグローバルキューに投げると、GCD のスレッドプールを枯渇させかねません。重いスロットリングには、小さな専用キュー（あるいは、あとで扱う構造化された並行処理）のほうがうまく振る舞います。\n* **落とし穴:** セマフォが制限するのは一度に*いくつ*実行されるかであって、次に*どれ*が実行されるかではありません。タスクがパーミットを取得する順序に頼ってはいけません。\n* カウント 1 のセマフォはロックとして働きますが、より安全で忘れにくいツールが存在します。そして actor がこれを完全に置き換えることになります。\n\n---\n\n## 次は\n\n次の章は [並行処理の落とし穴](Concurrency%20Hazards.playgroundchapter/Overview) です。集計の例で垣間見た data race に加えて、デッドロックと優先度逆転、共有状態とブロッキングが衝突するときに何がうまくいかなくなるのか、そしてそれをどう推論するかを扱います。\n\n[前へ](@previous)  |  8 / 8 ページ";
