/* Page prose (ja) */
"Overview" = "# 並行処理の落とし穴\n\n作業をキューでメインスレッドから移し、Dispatch Group でバッチを待ち、セマフォでアクセスを制限してきました。ここからは鋭い刃の部分です。二つの作業が*同じ*値に同時に触れた瞬間、新しい種類のバグが現れます。自分のマシンではすべてのテストに通り、リリースされ、そして千人に一人のユーザーのために数値を壊すようなバグです。番号札を配る銀行の窓口を思い浮かべてください。共有された残高が一つ、窓口係が一列に並び、全員が同時に引き出しに手を伸ばします。この章は、彼らが協調しないときに何がうまくいかなくなるのか、そしてそれらを安全にするクラシックなツールについてです。\n\n---\n\n## このページで学ぶこと\n\n* **競合状態** と **data race** が何であるか、そしてコードを読んでそれを見抜く方法。\n* なぜ競合は **非決定的**（ほとんどの実行で正しく、一部の実行で誤る）で、そのために再現するのが恐ろしく難しいのか。\n* 二つのクラシックな解決策。書き込みを **シリアルキュー** に集約するか、**`.barrier` 付きの並行キュー**（リーダー・ライターパターン）を使う。\n* **デッドロック** とは何か、そしてアプリを永遠に凍りつかせる一行のミス。\n* **優先度逆転** とは何かを、平易な言葉で。\n* 何も実行せずにスレッド安全性を推論するためのチェックリスト。\n\n準備ができたら、次のページに進みましょう。わざと銀行の共有残高を壊してみます。\n\n1 / 9 ページ  |  [次へ: data race](@next)";
