競合状態(race condition)

複数のスレッドがどの順序で特定のコードに到達するかによって結果が変わってしまう不具合。

概念URI

https://comcomponent.com/knowledge/race-condition/

別名・表記

レースコンディション

最終確認日

2026-08-01

機械可読データ

JSON-LD

この概念が関わる関係

• 共有可変状態は競合状態(race condition)の原因になることがあります。count++は読み込み・加算・書き戻しの3ステップに分かれるため、同期がなければ2つのスレッドの加算のうち一方が失われる。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• Interlocked関数は競合状態(race condition)を防ぎます。InterlockedIncrement / Decrementは読み込み・加算・書き戻しを1つの原子操作に束ねる。同期がなければ2つのスレッドの更新が食い違う。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• volatileを競合状態(race condition)に用いることは推奨されません。volatileは原子性も順序も保証しない。共有カウンターやフラグの更新にはInterlocked系を使う。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• 共有可変状態は競合状態(race condition)の原因になることがあります。++countという1つの式も機械語では読み込み・加算・書き戻しの3ステップに分かれるため、2つのスレッドが同時に入ると一方の加算が上書きされて消える。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• std::shared_mutexは競合状態(race condition)を防ぎます。読み取りは多いが書き込みはまれなデータには、C++14のstd::shared_mutexで読み書きロックを使える。 / 確度: 条件付きの関係 / 確認日: 2026-08-02 出典
• std::atomicは競合状態(race condition)を防ぎます。アトミック操作は不可分なので、他スレッドからは操作の前か後の状態しか観測できない。memory_order引数にもとづいて他のアトミック操作の可視性への順序付け要件を確立し、それに反するコンパイラ最適化を抑止する。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• 共有可変状態は競合状態(race condition)の原因になることがあります。count++の1行は読み込み・加算・書き戻しの3ステップに分かれるため、2つのスレッドが同時に実行すると一方の加算がもう一方の書き戻しで上書きされて失われる。実行するたびに結果が変わり、どの結果になるかは予測できない。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• Interlockedは競合状態(race condition)を防ぎます。カウンターの増減やフラグの入れ替えのような単一変数の原子的更新は、lockよりInterlockedが高速で、競合がなければ単一のCPU命令プレフィックスで済む。複数の変数をまとめて整合させる用途には使えない。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• ReaderWriterLockSlimは競合状態(race condition)を防ぎます。ReaderWriterLockSlimは書き込みだけを排他して読み取りは同時アクセスを許すため、読み取りが頻繁で書き込みがまれな共有データに向く。 / 確度: 条件付きの関係 / 確認日: 2026-08-02 出典
• 共有可変状態は競合状態(race condition)の原因になることがあります。count++は読み込み・加算・書き戻しの3ステップに分かれるため、2つのスレッドが同時に入ると一方の加算が上書きされて消える。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• volatileを競合状態(race condition)に用いることは推奨されません。volatileは可視性と順序(happens-before)の保証であって、複合操作の原子性は与えない。フラグと単一値はAtomic系、複合状態はロックにする。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• Atomic系クラス(AtomicInteger / LongAdder)は競合状態(race condition)を防ぎます。単一変数の原子的更新はAtomicInteger / AtomicLong / AtomicReferenceが受け持ち、高頻度に加算するだけの統計値なら競合に強いLongAdderを使う。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• ConcurrentHashMap.computeIfAbsentは競合状態(race condition)を防ぎます。computeIfAbsentはメソッド呼び出し全体が原子的に実行され、キー不在時にマッピング関数がその1回の呼び出しの中でちょうど1回だけ呼ばれる。原子的である代償として計算中は他スレッドの一部の更新がブロックされるため、マッピング関数は短く保ち、関数の中でこのマップ自体を更新してはいけない。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
• 述語のwhileループ再確認は競合状態(race condition)を防ぎます。スプリアスウェイクアップも横取りも発生自体は消せないが、waitから戻るたびに待っていた条件そのものを確認し、成立していなければもう一度眠ることで、条件不成立のまま処理が進むことを防げる。3つのどの経路で戻ってきたかを呼び出し側は区別できないため、これが唯一の戦略になる。公式の生産者・消費者キューの使用例も待機をwhileループで書いている。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典 出典
• スプリアスウェイクアップは競合状態(race condition)の原因になることがあります。ifで1回だけ確認して待機に入るコードは、スプリアスウェイクアップか横取りが起きた瞬間に条件不成立のまま処理が進み、空のキューからの取り出しや未初期化データの参照といった、たまにしか出ないクラッシュ・データ破損になる。 / 確度: 条件付きの関係 / 確認日: 2026-08-22 出典

この概念を扱う記事

• マルチスレッドの実務ベストプラクティス C言語編 ── Win32 APIの流儀で安全に書く(主要トピック)
• マルチスレッドの実務ベストプラクティス C++編 ── RAIIとjthreadで事故を構造から消す(言及)
• マルチスレッドの実務ベストプラクティス .NET編 ── スレッドを増やす前に決めておくこと(主要トピック)
• マルチスレッドの実務ベストプラクティス Java編 ── 仮想スレッド時代の定石(言及)
• スプリアスウェイクアップ ── 条件変数が「通知なしに目覚める」理由とWindowsでの正しい待ち方(言及)

一次資料

• https://learn.microsoft.com/dotnet/standard/threading/managed-threading-best-practices

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。