Spurious Wakeup — ทำไม condition variable จึงตื่น "โดยไม่ถูกแจ้ง" และวิธีรออย่างถูกต้องบน Windows

“เราใส่ข้อมูลในคิวแล้วปลุกเธรดเวิร์กเกอร์ที่กำลังรอ มันรันมาหกเดือน แล้ววันหนึ่งมันพยายามอ่านคิวว่างแล้วล่ม” “เรากำลังส่งการแจ้ง แต่บางครั้งเธรดไม่เคยตื่น” — การนัดพบแบบมัลติเธรดดูราวกับว่าทำงาน และเป็นแหล่งเพาะบั๊กที่ปรากฏเฉพาะน้อยครั้ง การสอบสวนชนิดนี้มักลงที่โค้ดที่ห่อ wait ของ condition variable ด้วย if และข้างหลังนั้นนั่ง spurious wakeup — ปรากฏการณ์ของการกลับจาก wait โดยไม่ได้รับการแจ้ง

“มันตื่นแม้ไม่มีใครแจ้ง” ฟังเหมือนข้อบกพร่องของการอิมพลีเมนต์ แต่เป็นพฤติกรรมที่ Win32, C++ และ POSIX ทั้งหมดระบุในเอกสารหรือมาตรฐาน และ Monitor ของ .NET ถูกออกแบบบนสมมติฐานว่า “เมื่อถูกปลุก คุณตรวจเงื่อนไขอีกครั้ง” ทำไมพฤติกรรมนั้นจึงถูกอนุญาต มันเกิดที่ชั้นใดบน Windows และคุณเขียนการรออย่างไรให้ไม่ชน มัน มุ่งไปที่นักพัฒนาที่เขียนแอปธุรกิจและซอฟต์แวร์ควบคุมอุปกรณ์บน Windows บทความนี้แกะว่า spurious wakeup คืออะไรจริง ๆ จากแหล่งปฐมภูมิ และต้มการรอที่ถูกต้องลงเป็น Win32 (C), C++ และ C#

1. สรุปก่อนเลย

• wait ของ condition variable สามารถกลับได้แม้ไม่มีการแจ้งมาถึง เอกสารทางการของ Win32 ระบุว่า condition variable อยู่ภายใต้ spurious wakeup (การตื่นที่ไม่ผูกกับการปลุกที่ชัดเจน) และ stolen wakeup (เธรดอื่นบริโภคเงื่อนไขก่อนเธรดที่ถูกปลุก)¹
• ดังนั้นคุณต้องเขียนการรอเสมอเป็น “ลูป while บวกการตรวจเงื่อนไขอีกครั้ง” โค้ดที่ตรวจครั้งเดียวด้วย if แล้ว wait ดูราวกับว่าทำงาน และซ่อนบั๊กที่ทำซ้ำได้เฉพาะน้อยครั้ง¹²
• นี่ไม่ใช่ความแปลกเฉพาะ Windows POSIX และมาตรฐาน C++ กล่าวสิ่งเดียวกัน การอิมพลีเมนต์ที่ “ไม่เคยตื่นปลอมเด็ดขาด” จะทำให้การทำงานของ condition variable ทุกครั้งช้าลง ดังนั้นการตื่นถูกอนุญาตบนสมมติฐานว่าฝั่งที่รอจะตรวจอีกครั้ง³⁴
• ใน C++ รูป predicate wait(lock, pred) ให้ไลบรารีทำลูปแทนคุณ รูปนั้นโดยพฤตินัยรัน while (!pred()) wait(lock); มันคือค่าเริ่มต้นสำหรับโค้ดใหม่⁵
• Monitor.Wait ของ C# ต้องการวินัยเดียวกัน เงื่อนไขอาจถูกบริโภคในช่วงระหว่างถูกปลุกกับการถือล็อกใหม่ ดังนั้นคุณตรวจเงื่อนไขอีกครั้งใน while แล้วกลับไป Wait⁶
• อัปเดตและตรวจเงื่อนไขภายใต้ล็อกเดียวกัน หากคุณดูเงื่อนไขนอกล็อกแล้วเข้า wait การแจ้งสามารถผ่านช่องว่าง — lost wakeup¹
• อย่าสร้างการแจ้งชั่วคราวแบบ “ปลุกผู้ที่กำลังรอตอนนี้” ของ condition variable ด้วย pulse บนอีเวนต์ PulseEvent โดยเฉพาะอาจพลาดการแจ้งในชั่วขณะที่ kernel-mode APC ยกการรอสั้น ๆ และ Microsoft เองกล่าวตรง ๆ ว่า “มันไม่น่าเชื่อถือ อย่าใช้ ใช้ condition variable แทน”⁷

สิ่งที่ตามมาเดินผ่านกลไกที่รองรับข้อสรุปนี้ ตามลำดับ

2. Spurious Wakeup คืออะไร — การตื่นไม่หมายความว่าเงื่อนไขเป็นจริง

condition variable คือพริมิทีฟซิงโครไนซ์สำหรับ “ให้เธรดหลับจนกว่าเงื่อนไขบางอย่างเป็นจริง และให้มันถูกปลุกเมื่อเป็นจริง” บน Win32 นั่นคือโครงสร้าง CONDITION_VARIABLE คู่กับ SleepConditionVariableCS / SleepConditionVariableSRW (รอ) และ WakeConditionVariable / WakeAllConditionVariable (แจ้ง) API รอปล่อยล็อกที่คุณถืออยู่อย่างอะตอมมิก (critical section หรือ SRW lock) แล้วไปหลับ และตอนตื่นมันถือล็อกใหม่ก่อนกลับ¹

คำถามคือความจริงของ “ได้กลับจาก wait” หมายความว่าอะไรจริง ๆ โดยไร้เดียงสาคุณอยากคิดว่า “การแจ้งมาถึง = เงื่อนไขเป็นจริง” แต่ในความเป็นจริงมีสามกรณีที่ wait กลับ

flowchart TB
    accTitle: สามกรณีที่ wait กลับ
    accDescr: การรอของ condition variable สามารถกลับได้ไม่เฉพาะจากการแจ้งจริง แต่ยังจาก spurious wakeup ที่ไม่มีการแจ้ง และจาก stolen wakeup ที่การแจ้งมาถึงแต่เงื่อนไขถูกบริโภคก่อน ดังนั้นทุกกรณีต้องตรวจเงื่อนไขอีกครั้ง
    w["กลับจาก wait"] --> a["การแจ้งจริง"]
    w --> b["Spurious wakeup (ไม่มีการแจ้ง)"]
    w --> c["Stolen wakeup (เงื่อนไขถูกบริโภคแล้ว)"]
    a --> r["ตรวจเงื่อนไขอีกครั้ง แล้วเดินต่อ"]
    b --> r
    c --> r

ภาพ 1: มีสามเส้นทางกลับจาก wait และผู้เรียกบอกไม่ได้ว่าเดินเส้นใด ดังนั้นคุณต้องตรวจเงื่อนไขอีกครั้งเสมอ

spurious wakeup คือกรณีที่สองนี้ — ปรากฏการณ์ที่ API รอกลับโดยไม่ผูกกับการแจ้งที่ชัดเจนที่ตั้งใจปลุกคุณ มันไม่จำกัดเฉพาะสถานการณ์ที่ WakeConditionVariable ไม่เคยถูกเรียกที่ใดในระบบ ตัวอย่างเช่น ภายใต้โหลดสูงที่การแจ้งมาถึงเป็นชุดสั้น ๆ การอิมพลีเมนต์อาจปลุกเธรดที่รอเพิ่มเป็นชุด และจากฝั่งที่ไม่มีแจ้งที่สอดคล้อง นั่นก็คือ spurious wakeup เช่นกัน หน้า condition variable ของ Microsoft Learn กล่าวสิ่งนี้ตรง ๆ: “Condition variables are subject to spurious wakeups (those not associated with an explicit wake) and stolen wakeups (another thread manages to run before the woken thread). Therefore, you should recheck a predicate (typically in a while loop) after a wait operation returns.”¹

จุดสำคัญคือผู้เรียกบอกไม่ได้ว่ากลับผ่านกรณีใดในสามกรณี หากบอกไม่ได้ มีกลยุทธ์เดียวที่ใช้ได้: ทุกครั้งที่กลับ ให้ตรวจเงื่อนไขที่คุณกำลังรอเอง และกลับไปหลับหากมันไม่เป็นจริง นั่นคือเนื้อหาจริงของกฎเหล็ก “ห่อ wait ด้วย while” พูดกลับกัน ตราบที่คุณคงกฎนั้น โค้ดถูกต้องไม่ว่ากรณีใดในสามกรณีปลุกคุณ

3. ทำไมข้อกำหนดจึงอนุญาต — การแจ้งที่แม่นยำแพง

“การตื่นโดยไม่ถูกแจ้งเป็นการอิมพลีเมนต์ที่เลอะเทอะไม่ใช่หรือ” เป็นคำถามที่ยุติธรรม จริง ๆ แล้วเป็นไปได้ในทางทฤษฎีที่จะสร้างการอิมพลีเมนต์ที่ไม่เคยตื่นปลอม แม้เช่นนั้น POSIX, Windows และมาตรฐาน C++ ทั้งหมดลงเอยฝั่ง “มันเกิดได้” เหตุผลถูกกล่าวตรง ๆ ใน Rationale ของ pthread_cond_wait ใน POSIX (The Open Group Base Specifications)³

เหตุผลแรกคือประสิทธิภาพ การพยายามอิมพลีเมนต์การแจ้งที่ “ปลุกเธรดพอดีหนึ่งเส้นอย่างน่าเชื่อถือ” อย่างเคร่งครัด โดยเฉพาะบนมัลติโปรเซสเซอร์ เพิ่มต้นทุนซิงโครไนซ์พิเศษให้การทำงานของ condition variable ทุกครั้ง ตัวจัดตารางนั่งระหว่างการแจ้งกับการปลุก และขึ้นกับจังหวะของการขัดจังหวะและการแย่ง คุณเลี่ยง “เธรดอื่นรันก่อนเธรดที่คุณตั้งใจปลุก” ไม่ได้ การให้ทุกคนจ่ายต้นทุนของการปิดสิ่งนั้นให้สนิทแย่กว่า สำหรับการทำให้ condition variable เร็ว กว่าการยอมรับว่า “คุณอาจปลุกเพิ่มเป็นครั้งคราว”

เหตุผลที่สองคือข้อสังเกตว่าการแลกนี้ไม่ทำลายแอป — มันทำให้พวกมันแข็งแรงกว่าจริง ๆ เพราะ spurious wakeup ถูกอนุญาต โค้ดที่ถูกต้องเขียนลูปที่ตรวจ predicate (เงื่อนไขที่กำลังรอ) เสมอ Rationale ของ POSIX กล่าวว่าการบังคับลูปนี้ทำให้โค้ดอธิบายตนเองและแข็งแรงกว่า³ เมื่อลูปอยู่แล้ว ความหมายของการแจ้งถูกลดจาก “ประกันว่าเงื่อนไขเป็นจริง” เป็น “คำใบ้ว่าเงื่อนไขอาจเปลี่ยน” และฝั่งที่รอทนต่อการเปลี่ยนการออกแบบเล็กน้อยของฝั่งที่แจ้ง (ปลุกมากเกินไป ปลุกเป็นชุด เป็นต้น)

stolen wakeup เป็นเรื่องเชิงโครงสร้างยิ่งกว่า มีช่องว่างของเวลาเสมอระหว่างที่ฝั่งที่แจ้งเรียก WakeConditionVariable กับที่เธรดที่ถูกปลุกถือล็อกใหม่แล้วกลับจาก wait หากเธรดที่สามถือล็อกในช่วงนั้นได้ มันสามารถบริโภคเงื่อนไข (เนื้อหาของคิว เป็นต้น) ก่อน นั่นคือช่องว่างที่การขัดเกลาการอิมพลีเมนต์ไม่ว่าเท่าใดก็ลบไม่ได้ เพราะมันมาจากรูปของเครื่องมือ condition variable เอง

sequenceDiagram
    accTitle: ไทม์ไลน์ของ stolen wakeup
    accDescr: ผู้ผลิตใส่หนึ่งรายการในคิวแล้วปลุกผู้บริโภค A ที่กำลังรอ แต่ก่อน A ถือล็อกใหม่ ผู้บริโภค B ถือล็อกแล้วเอาหนึ่งรายการ ดังนั้นคิวว่างเมื่อ A ตื่น
    participant A as ผู้บริโภค A (กำลังรอ)
    participant P as ผู้ผลิต
    participant B as ผู้บริโภค B
    P->>P: เพิ่มหนึ่งรายการเข้าคิว
    P->>A: WakeConditionVariable
    Note over A: ถูกปลุก กำลังรอถือล็อกใหม่
    B->>B: ถือล็อกแล้วเอาหนึ่งรายการ
    A->>A: ถือล็อกใหม่แล้วกลับจาก wait
    Note over A: คิวว่าง (ถูกขโมย)
    A->>A: ตรวจอีกครั้งในลูป while แล้วรออีก

ภาพ 2: “stolen wakeup” ที่เธรดที่สามบริโภคเงื่อนไขในช่องว่างเวลาระหว่างการแจ้งกับการปลุก สามารถเกิดภายใต้การอิมพลีเมนต์ใดก็ได้

กล่าวอีกนัย แม้ OS กำจัด spurious wakeup ให้หมดสิ้น ตราบที่ stolen wakeup มีอยู่ คุณยังเขียน “ฉันตื่น = เงื่อนไขเป็นจริง” ไม่ได้ ลูปตรวจอีกครั้งของฝั่งที่รอถูกต้องการอยู่แล้ว และเมื่อเป็นเช่นนั้น การอนุญาต spurious wakeup แล้วคงการอิมพลีเมนต์ให้เร็วถูกกว่า — นั่นคือการตัดสินออกแบบที่ condition variable ถือมานานหลายทศวรรษ

4. มันปรากฏที่ชั้นใดบน Windows

คุณสมบัตินี้โชว์หน้าไม่ว่าคุณจะใช้ชั้นใดของพริมิทีฟซิงโครไนซ์บน Windows เพื่อรู้สึกว่าคุณหนีมันไม่ได้ไม่ว่าจะเขียนกับ API ของชั้นใด เราจะดูชั้นตัวแทน

condition variable ของ Win32 (CONDITION_VARIABLE) ตามที่กล่าวแล้ว ถูกบันทึกบน SleepConditionVariableCS / SleepConditionVariableSRW ว่าอยู่ภายใต้ทั้ง spurious wakeup และ stolen wakeup และคุณถูกต้องการให้ตรวจ predicate อีกครั้งในลูป while² ตัวอย่างการใช้งานอย่างเป็นทางการ (คิวผู้ผลิต–ผู้บริโภค) ก็เขียนการรอภายในลูป while⁸

WaitOnAddress ที่ชั้นต่ำกว่าอีก คือ API รอที่ดั้งเดิมกว่า condition variable: “รอจนกว่าค่าที่ที่อยู่ที่ให้เปลี่ยน” (Windows 8 เป็นต้นไป) แม้ API ใกล้ก้นชั้นนี้ก็มีเอกสารที่ระบุว่า “มันถูกประกันว่าจะกลับเมื่อที่อยู่ถูกสัญญาณ แต่ยังได้รับอนุญาตให้กลับด้วยเหตุอื่น” และยกตัวอย่างของการตื่นเร็วเป็นสภาพหน่วยความจำต่ำ การทิ้งการปลุกก่อนหน้าสำหรับที่อยู่เดียวกัน และการรัน checked build นั่นคือเหตุที่ตัวอย่างการใช้งานของเอกสารเองอยู่ในรูปของ “ลูป while ที่เปรียบเทียบค่าอีกครั้ง”⁹

std::condition_variable ของ C++ ก็เหมือนกัน เอกสารของ MSVC กล่าวถึง wait ที่ไม่มี predicate ว่ามัน “บล็อกจนกว่าถูกสัญญาณโดยการเรียก notify_one / notify_all มันยังอาจตื่นปลอม” และอธิบายว่ารูป predicate wait(lock, pred) โดยพฤตินัยรันโค้ดต่อไปนี้⁵

while (!Pred())
    wait(Lck);

กล่าวอีกนัย wait รูป predicate ที่แนะนำใน C++ ไม่ใช่อื่นใดนอกจากไลบรารีรับ “ห่อด้วย while” ตามที่บทความนี้อธิบาย แทนคุณ cppreference เช่นกันระบุว่า wait ที่ไม่มี predicate สามารถถูกปลดบล็อกแบบปลอมได้⁴

Monitor.Wait / Pulse ของ .NET มีโครงสร้างคิวของตนเองคือคิวรอและคิวพร้อม แต่วินัยไม่เปลี่ยน เธรดที่ถูกปลุกโดย Pulse / PulseAll ย้ายไปคิวพร้อมแล้วกลับจาก Wait ตามลำดับที่ถือล็อกใหม่ได้ การที่เธรดอื่นบริโภคเงื่อนไขได้ในช่วงก่อนล็อกถูกถือใหม่เหมือนกับบน Win32 และเอกสารก็ถูกเขียนบนสมมติฐานว่า “เธรดที่ถูกปลุกประเมินเงื่อนไขที่ทำให้มันเข้าสู่การรออีกครั้ง และเรียก Wait อีกหากจำเป็น”⁶¹⁰

flowchart TB
    accTitle: ทุกชั้นต้องการให้ตรวจ predicate อีกครั้ง
    accDescr: เอกสารทางการต้องการให้ตรวจเงื่อนไขอีกครั้งหลังตื่นที่ทุกชั้น — C++ std::condition_variable, .NET Monitor, Win32 CONDITION_VARIABLE และ WaitOnAddress ชั้นต่ำ
    cpp["C++ std::condition_variable"] --> rule["ตอนตื่น ตรวจเงื่อนไขอีกครั้ง (while)"]
    net[".NET Monitor.Wait"] --> rule
    win["Win32 CONDITION_VARIABLE"] --> rule
    woa["WaitOnAddress"] --> rule

ภาพ 3: เปลี่ยนภาษาหรือเฟรมเวิร์ก และข้อกำหนดทางการยังเหมือนกันที่ทุกชั้นของพริมิทีฟรอ: ตรวจอีกครั้งหลังคุณตื่น

5. วิธีรอที่ถูกต้อง — เขียนด้วย while และ predicate

จากนี้ไป การอิมพลีเมนต์ มีหลักการเพียงสามข้อ

1. ถือสิ่งที่คุณรอเป็นสถานะ (predicate) ไม่ใช่เป็น “การแจ้ง” เงื่อนไขคือสถานะที่ใช้ร่วมที่ถูกล็อกปกป้อง — “คิวไม่ว่างหรือไม่” “แฟล็กถูกตั้งหรือไม่” — ไม่ใช่ “ฉันถูกปลุกหรือไม่”
2. วาง wait ภายในลูป while บนเงื่อนไขเสมอ แต่ละครั้งที่ตื่น ตรวจเงื่อนไข และกลับไปหลับหากไม่เป็นจริง
3. อัปเดตและตรวจเงื่อนไขภายใต้ล็อกเดียวกัน ฝั่งที่แจ้งอัปเดตสถานะแล้วจึงแจ้ง

flowchart TB
    accTitle: ลำดับของลูปรอที่ถูกต้อง
    accDescr: ถือล็อกแล้วตรวจเงื่อนไข หากไม่เป็นจริง ปล่อยล็อกแล้วหลับ ตอนตื่นถือล็อกใหม่แล้วกลับสู่การตรวจเงื่อนไข เดินต่อโดยถือล็อกเฉพาะเมื่อเงื่อนไขเป็นจริง
    l["ถือล็อก"] --> c{"เงื่อนไขเป็นจริงหรือไม่?"}
    c -->|"ไม่"| s["wait (ปล่อยล็อกแล้วหลับ)"]
    s --> wk["ตื่น (ถือล็อกใหม่)"]
    wk --> c
    c -->|"ใช่"| go["เดินต่อขณะยังถือล็อก"]

ภาพ 4: การรอที่ถูกต้องคือลูป และไม่มีช่องว่างระหว่างการตรวจเงื่อนไขกับการประมวลผล (ทั้งคู่เกิดขณะถือล็อก)

รูปนี้มีประโยชน์ที่พลาดง่าย ชั่วขณะที่คุณออกจากลูป while มันถูกสถาปนา ขณะที่คุณยังถือล็อก ว่า “เงื่อนไขเป็นจริง” ลูปที่ป้องกัน spurious wakeup คือ ตามที่เป็น ประกันว่าไม่มีช่องว่างเงื่อนไขแข่งระหว่างการตรวจเงื่อนไขกับการประมวลผลมัน

รูปพื้นฐานใน Win32 (C)

CRITICAL_SECTION cs;
CONDITION_VARIABLE cv;
int queueCount = 0;   // shared state protected by cs

// Initialise once at startup (for static initialisation, cv = CONDITION_VARIABLE_INIT)
InitializeCriticalSection(&cs);
InitializeConditionVariable(&cv);

// Waiter (consumer)
EnterCriticalSection(&cs);
while (queueCount == 0) {                       // always while, never if
    SleepConditionVariableCS(&cv, &cs, INFINITE);
}
// Here the lock is held and queueCount > 0 is guaranteed
--queueCount;
LeaveCriticalSection(&cs);

// Notifier (producer)
EnterCriticalSection(&cs);
++queueCount;                                    // update the state under the lock
LeaveCriticalSection(&cs);
WakeConditionVariable(&cv);                      // notifying after releasing the lock is fine

คุณเรียกการแจ้ง (WakeConditionVariable) จากภายในล็อกหรือจากภายนอกได้ แต่เอกสารกล่าวว่าการปลุกหลังปล่อยล็อกมักดีกว่า เพื่อลดการสลับบริบท¹ ในทางกลับกัน การอัปเดตสถานะเอง (++queueCount) ต้องเกิดภายใต้ล็อกเสมอ อย่าสับสนทั้งสองอย่าง

รูปพื้นฐานใน C++ — ทำให้ predicate wait เป็นค่าเริ่มต้น

std::mutex m;
std::condition_variable cv;
std::queue<Item> q;

// Waiter
std::unique_lock<std::mutex> lk(m);
cv.wait(lk, [&] { return !q.empty(); });   // internally while(!pred) wait
Item item = std::move(q.front());
q.pop();
lk.unlock();

// Notifier
{
    std::lock_guard<std::mutex> lk(m);
    q.push(std::move(item));
}
cv.notify_one();

เพราะ wait รูป predicate ทำลูปแทนคุณ while ที่เขียนมือจึงไม่จำเป็น เมื่อคุณแก้โค้ดที่มีอยู่ที่ยังมีลูปเขียนมือ while (q.empty()) cv.wait(lk); คือรูปที่ถูกต้อง จึงไม่จำเป็นต้องรีบเขียนใหม่ รูปเดียวที่ไม่ถูกต้องคือ if (q.empty()) cv.wait(lk);

รูปพื้นฐานใน C#

private readonly object _gate = new();
private readonly Queue<Item> _queue = new();

// Waiter
lock (_gate)
{
    while (_queue.Count == 0)          // always while, never if
    {
        Monitor.Wait(_gate);
    }
    var item = _queue.Dequeue();
}

// Notifier
lock (_gate)
{
    _queue.Enqueue(item);
    Monitor.Pulse(_gate);              // Monitor.Pulse can only be called inside the lock
}

Monitor.Wait / Pulse / PulseAll เรียกได้เฉพาะจากภายในล็อก (บล็อก lock) ซึ่งต่างจาก Win32 การเรียกนอกล็อกโยน SynchronizationLockException¹⁰

การรอพร้อมหมดเวลา — คำนวณเวลาที่เหลือจากเส้นตาย

เมื่อคุณรอพร้อมหมดเวลา การส่ง “ค่าหมดเวลาเดียวกัน” ทุกครั้งที่วนลูปยืดการรอแต่ละครั้งที่ spurious wakeup เกิด รูปที่ถูกต้องคือตรึงเส้นตายก่อนแล้วคำนวณเวลาที่เหลือใหม่

ULONGLONG deadline = GetTickCount64() + timeoutMs;
EnterCriticalSection(&cs);
while (queueCount == 0) {
    ULONGLONG now = GetTickCount64();
    if (now >= deadline) {
        break;                          // timeout (condition still unsatisfied)
    }
    if (!SleepConditionVariableCS(&cv, &cs, (DWORD)(deadline - now)) &&
        GetLastError() != ERROR_TIMEOUT) {
        break;                          // on failure other than timeout, stop waiting and leave
    }
    // Confirm ERROR_TIMEOUT finally via the while condition and the deadline check
}
BOOL ready = (queueCount > 0);
if (ready) { --queueCount; }
LeaveCriticalSection(&cs);

flowchart TB
    accTitle: ลำดับที่ถูกต้องของการรอพร้อมหมดเวลา
    accDescr: ตรึงเส้นตายก่อน และแต่ละครั้งที่ตื่นตรวจเงื่อนไขกับเส้นตาย หากยังมีเวลา คำนวณเวลาที่เหลือใหม่แล้วกลับสู่การรอ
    d["ตรึงเส้นตาย"] --> c{"เงื่อนไขเป็นจริงหรือไม่?"}
    c -->|"ใช่"| go["เดินต่อไปประมวลผล"]
    c -->|"ไม่"| t{"เส้นตายผ่านไปแล้วหรือไม่?"}
    t -->|"ใช่"| to["จัดการหมดเวลา"]
    t -->|"ไม่"| w["คำนวณเวลาที่เหลือแล้วรอ"]
    w --> c

ภาพ 5: การรอพร้อมหมดเวลาไม่ส่ง “ระยะรอเดียวกัน” อีก มันคำนวณเวลาที่เหลือใหม่จากเส้นตาย

ใน C++ คุณปล่อยการคำนวณนี้ รวมเส้นตาย ให้โอเวอร์โหลด wait_until (เวลาสัมบูรณ์) บวก predicate ได้ แม้เมื่อมันกลับตอนหมดเวลา มันให้ค่าสุดท้ายของ predicate ดังนั้นคุณยังตัดสิน “เราหมดเวลา หรือเราทัน” จาก predicate ได้⁵

6. รายการรูปแบบที่ควรหลีกเลี่ยง

การตรวจครั้งเดียวด้วย if นี่คือดาวของบทความ ชั่วขณะที่ spurious wakeup หรือ stolen wakeup เกิด การประมวลผลเดินต่อโดยเงื่อนไขไม่เป็นจริง การเอาจากคิวว่าง การแตะข้อมูลที่ยังไม่เริ่มต้น double free — อาการกลายเป็น “การล่มหรือการเสียข้อมูลที่ปรากฏเฉพาะเป็นครั้งคราว”

การตรวจหรืออัปเดตเงื่อนไขนอกล็อก หากฝั่งที่รอดูเงื่อนไขนอกล็อก ตัดสินว่า “ยังไม่” และในช่องว่างก่อนเข้า wait ฝั่งที่แจ้งอัปเดตสถานะแล้วส่งการแจ้ง การแจ้งถูกยิงไปที่ condition variable ที่ไม่มีผู้รอแล้วหายไป ฝั่งที่รอจากนั้นเข้า wait แล้วรอการแจ้งที่จะไม่มาอีก นั่นคือ lost wakeup ภาพสะท้อนของ spurious wakeup เหตุที่ API รอของ condition variable ถูกออกแบบให้ “ปล่อยล็อกอย่างอะตอมมิกแล้วไปหลับ” คือเพื่อปิดช่องว่างนี้พอดี¹ มันไม่เกิดตราบที่คุณคงวินัยล็อก

sequenceDiagram
    accTitle: ไทม์ไลน์ของ lost wakeup
    accDescr: หากฝั่งที่รอตรวจเงื่อนไขนอกล็อก และฝั่งที่แจ้งอัปเดตสถานะแล้วแจ้งในช่องว่างก่อนเข้า wait การแจ้งถูกส่งไปยัง condition variable ที่ไม่มีผู้รอแล้วหายไป และฝั่งที่รอรอการแจ้งที่จะไม่มาอีก
    participant W as ฝั่งที่รอ
    participant N as ฝั่งที่แจ้ง
    W->>W: ตรวจเงื่อนไขนอกล็อก (ไม่เป็นจริง)
    N->>N: อัปเดตสถานะแล้วแจ้ง
    Note over N: ไม่มีผู้รอชั่วขณะนี้
    W->>W: เข้า wait
    Note over W: การแจ้งหายไปแล้วและมันไม่เคยตื่น

ภาพ 6: หากคุณตรวจเงื่อนไขนอกล็อก การแจ้งลอดผ่านช่องว่างระหว่างการตรวจกับ wait — “lost wakeup”

การสร้าง “การแจ้งชั่วคราว” ของ condition variable ด้วย pulse บนอีเวนต์ อีเวนต์เอง (CreateEvent + SetEvent) ไม่ใช่แอนตี้แพตเทิร์น สัญญาณปลุกในการตั้งค่าที่ผู้บริโภคคนเดียวประมวลผลคิวจนว่าง หรือคำสั่งหยุดที่เมื่อยกแล้วไม่ถูกหย่อน (manual-reset event) คือการใช้ที่ถูกต้องของอีเวนต์ และเมื่อคุณอยากรวมกับเป้าหมายรออื่นผ่าน WaitForMultipleObjects หรือข้ามขอบโปรเซส condition variable — ออบเจ็กต์โหมดผู้ใช้ที่แชร์ข้ามโปรเซสไม่ได้ — คืออันที่ใช้ไม่ได้¹ สิ่งที่อันตรายคือการพยายามสร้าง ด้วยการทำงานของอีเวนต์ การแจ้งชั่วคราวของ condition variable ที่ “ปลุกเฉพาะเธรดที่กำลังรอชั่วขณะนั้นและไม่ทิ้งสถานะ” ความคิดนั้นเกือบเสมอพาไปยังข้อถัดไป PulseEvent

การใช้ PulseEvent มันคือ API ที่บน manual-reset event “ปลุกทุกคนที่กำลังรอแล้วคืนอีเวนต์สู่สถานะไม่สัญญาณทันที” แต่ Microsoft เองระบุในเอกสารว่า “ฟังก์ชันนี้ไม่น่าเชื่อถือและไม่ควรใช้ มันมีอยู่หลัก ๆ เพื่อความเข้ากันได้ย้อนหลัง ใช้ condition variable แทน” เหตุผลคือเธรดที่กำลังรอสามารถถูกถอดออกจากสถานะรอชั่วคราวโดย kernel-mode APC แล้วกลับสู่การรอหลัง APC เสร็จ หาก PulseEvent ถูกเรียกในช่วงสั้นนั้น เธรดนั้นไม่ถูกรวมใน “ผู้ที่กำลังรอชั่วขณะที่ถูกเรียก” และไม่ถูกปลุก⁷ kernel APC คือสิ่งที่ OS ใช้ภายใน แอปควบคุมไม่ได้¹¹ ปัญหานี้ยังเป็นคำเตือนการวิเคราะห์สแตติก (C28648)¹² หาก spurious wakeup คือปัญหาของ “ปลุกเพิ่ม” นี่คือปัญหาของ “นอนเกินเมื่อควรตื่น” และลูป while ช่วยไม่ได้ — เพราะการแจ้งเองหายไป

การส่งเฉพาะการแจ้งก่อน โดยไม่ถือล็อก ก่อนอัปเดตสถานะ การเรียก WakeConditionVariable ขณะสถานะยังเก่า แล้วจึงถือล็อกและอัปเดตสถานะ — ในลำดับนั้น เธรดที่ถูกปลุกยังเห็นเงื่อนไขไม่เป็นจริงเมื่อตรวจ แล้วกลับไปหลับ หากไม่มีการแจ้งเพิ่ม มันอยู่ที่นั่น โปรดทราบว่าหากคุณเขียน “แจ้ง → อัปเดต → ปล่อย” ขณะยังถือล็อกเดียวกัน ไม่มีอันตรายจริง เพราะฝั่งที่รอตรวจเงื่อนไขไม่ได้จนกว่าถือล็อกใหม่ แม้เช่นนั้น เพื่อไม่ให้ผู้อ่านต้องตรวจเงื่อนไขความปลอดภัยนี้ทุกครั้ง จะปลอดภัยกว่าหากทำให้ลำดับ “อัปเดตสถานะภายใต้ล็อก แล้วแจ้งหลังจากนั้น” เป็นมาตรฐาน

7. วิธีสอบสวนเมื่อคุณพบมัน

บั๊กที่เกี่ยวข้องกับ spurious wakeup มีลักษณะ “ปรากฏเฉพาะน้อยครั้ง” ทำงานย้อนจากอาการ พวกมันแยกเป็นสองตระกูลต่อไปนี้

ตระกูล 1: การประมวลผลเดินต่อโดยเงื่อนไขไม่เป็นจริง ข้อยกเว้นหรือการล่มจากการเอาจากคิวว่าง ผลที่ขาด เป็นต้น สงสัยการรอที่ไม่มี predicate คุณหวีสิ่งนี้ออกได้เชิงกลในการตรวจทานโค้ด — ค้นหาที่ที่ cv.wait( มีอาร์กิวเมนต์เดียว และที่ที่ SleepConditionVariableCS / Monitor.Wait ถูกห่อด้วย if แทน while การตรวจนี้ไม่ต้องการรอการทำซ้ำ และเป็นการเคลื่อนที่ที่มีเลเวอเรจสูงสุดที่คุณมี

ตระกูล 2: เธรดที่ควรตื่นไม่ตื่น (แฮง) สงสัย lost wakeup (การตรวจเงื่อนไขนอกล็อก หรือการแจ้งนอกล็อกก่อนอัปเดตสถานะ) และ PulseEvent ถ่ายดัมป์จากโปรเซสที่แฮงแล้วดูสแตกของแต่ละเธรด และคุณระบุได้ว่าเธรดใดติดใน API รอใด จากที่นั่น ไล่ผ่านโค้ด “ใครควรส่งการแจ้งนั้น และในลำดับใด”

flowchart TB
    accTitle: ลำดับการแยกจากอาการ
    accDescr: หากการประมวลผลเดินต่อโดยเงื่อนไขไม่เป็นจริง ให้หวีการรอที่ไม่มี predicate ด้วยการค้นหาโค้ด หากเธรดไม่ตื่น ให้ระบุจุดรอจากดัมป์แล้วสงสัย lost wakeup หรือ PulseEvent
    s["บั๊กที่ปรากฏเฉพาะน้อยครั้ง"] --> a["การประมวลผลเดินต่อโดยเงื่อนไขไม่เป็นจริง"]
    s --> b["เธรดที่ควรตื่นไม่ตื่น"]
    a --> a1["ค้นหาโค้ดสำหรับการรอที่ไม่มี predicate"]
    b --> b1["ระบุเธรดที่กำลังรอจากดัมป์"]
    a1 -.-> a2["เปลี่ยน if เป็น while หรือใช้ predicate wait"]
    b1 -.-> b2["สงสัย lost wakeup หรือ PulseEvent"]

ภาพ 7: ว่าอาการคือ “เดินไกลเกินไป” หรือ “ไม่เคยตื่น” แยกทั้งสิ่งที่คุณสงสัยและวิธีสอบสวน

หากคุณอยากทำซ้ำ การเคลื่อนที่มาตรฐานคือขยายหน้าต่างแข่ง เพิ่มความสั่นของจังหวะด้วยการใช้เธรดมากกว่าคอร์กายภาพ การแทรก Sleep โดยเจตนาระหว่าง wait กับ notify และการรันทั้งบิลด์ดีบักและรีลีส เมื่อคุณยืนยันว่า “มันหยุดทำซ้ำหลังเราแก้การรอที่ไม่มี predicate” ให้เปรียบเทียบภายใต้ความเครียดเดียวกัน

8. สรุป — รายการตรวจ

• เส้นทางกลับจาก wait มีสาม — การแจ้งจริง spurious wakeup และ stolen wakeup — และผู้เรียกแยกพวกมันไม่ได้ ดังนั้นเขียนการรอเป็นลูป while บนเงื่อนไขเสมอ
• spurious wakeup คือพฤติกรรมที่ Win32, C++ และ POSIX อนุญาตโดยเจตนาเป็นการแลกกับประสิทธิภาพ และมันจะไม่หายไปด้วยการแก้ของ OS หรือการสลับไลบรารี Monitor.Wait ของ .NET ไม่ถูกสมมติว่าตื่นโดยไร้เหตุ แต่เพราะ stolen wakeup และหมดเวลา มีอยู่ วินัย while เดียวกันยังถูกต้องการ
• ใน C++ ใช้รูป predicate wait(lock, pred) เป็นค่าเริ่มต้น ไลบรารีทำลูป
• อัปเดตและตรวจเงื่อนไขภายใต้ล็อกเดียวกัน ส่งการแจ้ง “หลังอัปเดตสถานะ” การแจ้งของ Win32/C++ เกิดหลังปล่อยล็อกได้ Pulse ของ C# อยู่ภายในล็อกเท่านั้น
• สำหรับการรอพร้อมหมดเวลา ตรึงเส้นตายแล้วคำนวณเวลาที่เหลือใหม่ ใน C++ คือ wait_until บวก predicate
• อย่าสร้างการแจ้งชั่วคราวของ condition variable ด้วย pulse บนอีเวนต์ PulseEvent โดยเฉพาะคือสิ่งที่เอกสารทางการระบุตรง ๆ ว่า “อย่าใช้ ใช้ condition variable แทน” อีเวนต์เองยังเป็นเครื่องมือที่ถูกสำหรับคำสั่งหยุด การรวมกับ WaitForMultipleObjects และการซิงโครไนซ์ข้ามโปรเซส
• ในการตรวจทาน ค้นหาเชิงกลสำหรับ “การรอที่ไม่มี predicate” และ “if + wait” คุณฆ่าบั๊กที่ทำซ้ำน้อยครั้งได้โดยไม่รอการทำซ้ำ

spurious wakeup ตรงข้ามกับความแปลกของชื่อ รวมเหลือคำสำคัญหนึ่งบรรทัดสำหรับการแก้ — เปลี่ยน if เป็น while และข้างหลังบรรทัดนั้นนอนแนวคิดออกแบบของเครื่องมือ condition variable: “การแจ้งที่แม่นยำแพง ดังนั้นการตรวจเป็นความรับผิดชอบของฝั่งที่รอ” เข้าใจมันเป็นกลไก แล้วคุณควรใช้วินัยเดียวกันโดยไม่ลังเลเมื่อภาษาหรือเฟรมเวิร์กเปลี่ยน

บทความที่เกี่ยวข้อง

• แนวปฏิบัติมัลติเธรดเชิงปฏิบัติ: ฉบับ C++ — ตัดอุบัติเหตุด้วยโครงสร้างด้วย RAII และ jthread
• แนวปฏิบัติมัลติเธรดเชิงปฏิบัติ: ฉบับ C — เขียนอย่างปลอดภัยแบบ Win32 API
• แนวปฏิบัติมัลติเธรดเชิงปฏิบัติ: ฉบับ .NET — สิ่งที่ต้องตัดสินก่อนเพิ่มเธรด
• ทำไมบน Windows จึงควรใช้การรออีเวนต์มากกว่า Sleep(1)
• กับดักของ Shared Memory และแนวปฏิบัติจริง
• เชิงลึกของ Windows I/O (ตอนที่ 2) — I/O แบบซิงโครนัสและอะซิงโครนัส: ความหมายที่แท้จริงของ OVERLAPPED

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับการตรวจทานการออกแบบมัลติเธรด การสอบสวนหาสาเหตุ (การวิเคราะห์ดัมป์) ของการล่มและแฮงที่ “ทำซ้ำได้เฉพาะเป็นครั้งคราว” และการย้ายโค้ดซิงโครไนซ์เดิม (ที่พึ่งอีเวนต์และ PulseEvent เป็นต้น) ไปสู่ฐาน condition variable เริ่มจากการแยกอาการก็ได้ — โปรดติดต่อได้ตามสบาย

• ที่ปรึกษาด้านเทคนิคและการตรวจทานการออกแบบ
• การตรวจสอบบั๊กและวิเคราะห์หาสาเหตุที่แท้จริง
• การพัฒนาแอปพลิเคชัน Windows
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

spurious wakeup คือบั๊กของ OS หรือไลบรารีหรือไม่

ไม่ — เป็นพฤติกรรมที่ระบุในข้อกำหนด Win32 SleepConditionVariableCS, C++ std::condition_variable และ POSIX pthread_cond_wait ล้วนมีเอกสารทางการหรือมาตรฐานที่ระบุชัดว่าการตื่นที่ไม่ผูกกับการแจ้งสามารถเกิดได้ การอิมพลีเมนต์ที่ห้ามมันเป็นไปได้ในทางทฤษฎี แต่จะทำให้การทำงานของ condition variable ทุกครั้งช้าลง (โดยเฉพาะการแจ้งบนมัลติโปรเซสเซอร์) ดังนั้นการแลกคืออนุญาตบนความเข้าใจว่า "ความถูกต้องยังอยู่หากฝั่งที่รอตรวจเงื่อนไขอีกครั้ง" ยาจึงไม่ใช่รอการแก้ของ OS แต่เขียน wait ภายในลูป while เสมอ (หรือใช้ wait รูป predicate)

การห่อ wait ในลูป while ทำร้ายประสิทธิภาพหรือไม่

ในทางปฏิบัติต้นทุนเล็กน้อยจนไม่นับ ลูป while เพิ่มเพียงการตรวจเงื่อนไขพิเศษหนึ่งครั้งแต่ละครั้งที่คุณตื่น และนั่นคือการเปรียบเทียบราคาถูกขณะที่คุณถือล็อกอยู่แล้ว spurious wakeup เองหายาก ดังนั้นรอบลูปพิเศษเกิดเฉพาะในกรณีพิเศษ ต้นทุนของการทิ้งการตรวจเป็น if ในทางกลับกันคือ "บั๊กที่ทำซ้ำได้เฉพาะน้อยครั้ง" ที่การประมวลผลเดินต่อโดยเงื่อนไขไม่เป็นจริง — ไม่มีการเปรียบเทียบ สิ่งที่ครองต้นทุนการรอของ condition variable จริง ๆ คือการแย่งล็อกและความถี่ที่คุณแจ้ง ไม่ใช่ว่ามี while หรือไม่

หากใช้ wait รูป predicate ของ C++ ฉันลืม spurious wakeup ได้หรือไม่

สำหรับลูปรอ ใช่: cv.wait(lock, pred) โดยพฤตินัยคือ while (!pred()) wait(lock); ดังนั้นทั้ง spurious wakeup และ stolen wakeup ถูกดูดซับอัตโนมัติ โค้ด C++ ใหม่ควรใช้โอเวอร์โหลด predicate เป็นค่าเริ่มต้น คุณยังต้องปกป้องการอัปเดตสถานะที่ใช้ร่วมที่ predicate อ่านด้วย mutex เดียวกัน และฝั่งที่แจ้งยังต้องอัปเดตสถานะนั้นก่อนเรียก notify Predicate wait รับลูปแทนคุณ มันไม่รับวินัยล็อกแทนคุณ

ปัญหาเดียวกันเกิดกับ Monitor.Wait ของ C# หรือไม่

เกิด เธรดที่รอใน Monitor.Wait ถูกปลุกโดย Pulse/PulseAll แล้วถือล็อกใหม่ก่อนกลับจาก Wait แต่ในช่วงนั้นเธรดอื่นอาจถือล็อกก่อนแล้วบริโภคเงื่อนไข (stolen wakeup) เอกสารของ Microsoft ถูกเขียนบนสมมติฐานว่าเธรดที่ถูกปลุกประเมินเงื่อนไขที่ทำให้มันรออีกครั้ง และเรียก Wait อีกหากจำเป็น ดังนั้นรูปพื้นฐานใน C# ก็คือ while (!condition) Monitor.Wait(gate); ข้อจำกัดหนึ่งที่ต่างจาก Win32 คือคุณเรียก Wait/Pulse ได้เฉพาะจากภายในคำสั่ง lock

spurious wakeup เกิดด้วยเมื่อคุณรออีเวนต์ด้วย WaitForSingleObject หรือไม่

ในการรอธรรมดา (ไม่ alertable) WAIT_OBJECT_0 ถูกคืนเฉพาะเมื่อออบเจ็กต์กลายเป็น signaled จริง ไม่มีการ "ตื่นไร้เหตุ" แบบที่ condition variable มี อย่างไรก็ตาม "อีเวนต์กลายเป็น signaled" กับ "เงื่อนไขของแอปเป็นจริง" เป็นคนละเรื่อง หากผู้บริโภคหลายคนถูกปลุกโดยอีเวนต์เดียวกัน เธรดที่ถือล็อกก่อนบริโภคเงื่อนไข ดังนั้นคุณยังต้องตรวจเงื่อนไขอีกครั้งหลังตื่น การออกแบบที่พยายามสร้างการแจ้งชั่วคราวแบบ "ปลุกเฉพาะผู้ที่กำลังรอชั่วขณะนั้น" ของ condition variable ด้วยอีเวนต์ยังมักชนปัญหาความน่าเชื่อถือของ PulseEvent ดังนั้นสำหรับการรอเงื่อนไขภายในโปรเซส condition variable คือเครื่องมือที่ปลอดภัยกว่า

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก