ทำไม pthread_cond_wait ถึงมีการปลุกที่ผิดพลาด?

ในการอ้างถึงหน้าคน:

เมื่อใช้ตัวแปรเงื่อนไขจะมีเพรดิเคตของบูลีนที่เกี่ยวข้องกับตัวแปรที่แชร์ซึ่งเกี่ยวข้องกับแต่ละเงื่อนไขรอซึ่งเป็นจริงถ้าเธรดควรดำเนินการต่อ การปลุกที่เกิดขึ้นจริงจาก pthread_cond_timedwait () หรือฟังก์ชั่น pthread_cond_wait () อาจเกิดขึ้นได้ เนื่องจากการส่งคืนจาก pthread_cond_timedwait () หรือ pthread_cond_wait () ไม่ได้มีความหมายอะไรเกี่ยวกับมูลค่าของเพรดิเคตนี้เพรดิเคตควรได้รับการประเมินอีกครั้งเมื่อส่งคืนดังกล่าว

ดังนั้นpthread_cond_waitสามารถส่งคืนแม้ว่าคุณจะไม่ได้ส่งสัญญาณ อย่างน้อยครั้งแรกที่ดูเหมือนว่าเลวร้าย มันจะเป็นฟังก์ชั่นที่สุ่มคืนค่าผิดหรือสุ่มคืนก่อนที่มันจะถึงคำสั่ง return ที่เหมาะสม ดูเหมือนว่าเป็นข้อบกพร่องที่สำคัญ แต่ความจริงที่ว่าพวกเขาเลือกที่จะจัดทำเอกสารนี้ในหน้าคนมากกว่าแก้ไขดูเหมือนว่าจะมีเหตุผลที่ถูกต้องว่าทำไมpthread_cond_waitตื่นขึ้นมาอย่างเก๊ สันนิษฐานว่ามีบางอย่างที่แท้จริงเกี่ยวกับวิธีการทำงานที่ทำให้ไม่สามารถช่วยเหลือได้ คำถามคืออะไร

ทำไมไม่pthread_cond_waitกลับ spuriously? ทำไมถึงไม่สามารถรับประกันได้ว่าจะมีการปลุกเมื่อมีการส่งสัญญาณอย่างถูกต้องเท่านั้น ทุกคนสามารถอธิบายเหตุผลของพฤติกรรมหลอกลวงได้หรือไม่

คำอธิบายต่อไปนี้ให้โดย David R. Butenhof ใน"การเขียนโปรแกรมด้วย POSIX หัวข้อ" (หน้า 80):

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

ในการอภิปราย comp.programming.threadsต่อไปนี้เขาขยายความคิดที่อยู่เบื้องหลังการออกแบบ:

Patrick Doyle เขียนว่า: 
> ในบทความ Tom Payne เขียนว่า: 
>> Kaz Kylheku wrote: 
>>: เนื่องจากการใช้งานบางครั้งไม่สามารถหลีกเลี่ยงการแทรกได้ 
>>: Wakeups ปลอมเหล่านี้ อาจมีค่าใช้จ่ายสูงในการป้องกัน

>> แต่ทำไม ทำไมเรื่องนี้ถึงยากนัก ตัวอย่างเช่นเรากำลังพูดถึง
>> สถานการณ์ที่การรอคอยหมดเวลาเมื่อมีสัญญาณเข้ามา? 

> คุณรู้ไหมฉันสงสัยว่าผู้ออกแบบ pthreads ใช้ตรรกะเช่นนี้หรือไม่: 
> ผู้ใช้ตัวแปรเงื่อนไขต้องตรวจสอบเงื่อนไขเมื่อออกแล้ว 
> ดังนั้นเราจะไม่วางภาระเพิ่มเติมใด ๆ กับพวกเขาหากเราอนุญาต 
> Wakeups ปลอม; และเนื่องจากเป็นไปได้ที่อนุญาตให้ปลอม
> การปลุกอาจทำให้การติดตั้งเร็วขึ้นซึ่งจะช่วยได้ก็ต่อเมื่อเรา 
> อนุญาต 

> พวกเขาอาจไม่มีการนำไปปฏิบัติโดยเฉพาะในใจ 

จริงๆแล้วคุณอยู่ไม่ไกลเลยยกเว้นว่าคุณไม่ได้ผลักมันมากพอ 

ความตั้งใจที่จะบังคับให้ถูกต้อง / รหัสที่มีประสิทธิภาพโดยต้องการลูปภาคแสดง นี้คือ
ขับเคลื่อนโดยนักวิชาการที่ถูกต้องพิสูจน์ในหมู่ "แกนด้าย" ใน 
คณะทำงานแม้ว่าฉันจะไม่คิดว่าใครจะไม่เห็นด้วยกับเจตนา 
เมื่อพวกเขาเข้าใจสิ่งที่มันหมายถึง 

เราทำตามความตั้งใจนั้นพร้อมด้วยเหตุผลหลายระดับ อย่างแรกก็คือ
"เคร่งครัด" โดยใช้การวนซ้ำช่วยปกป้องแอปพลิเคชันจากความไม่สมบูรณ์ของตัวเอง 
การปฏิบัติที่เข้ารหัส อย่างที่สองก็คือมันไม่ยากที่จะจินตนาการอย่างเป็นนามธรรม
เครื่องจักรและรหัสการใช้งานที่สามารถใช้ประโยชน์จากข้อกำหนดนี้เพื่อปรับปรุง 
ประสิทธิภาพของการดำเนินการตามเงื่อนไขเฉลี่ยรอการปรับให้เหมาะสม 
กลไกการซิงโครไนซ์ 
/ ------------------ [David.Buten ... @ compaq.com] ------------------ \ 
| Compaq Computer Corporation POSIX สถาปนิกสถาปนิก |
| หนังสือของฉัน: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\ ----- [http://home.earthlink.net/~anneart/family/dave.html] ----- / 

อย่างน้อยสองสิ่งที่ 'การปลุกให้ดีลวงตา' อาจหมายถึง:

• เธรดที่ถูกบล็อกในpthread_cond_waitสามารถส่งคืนจากการโทรแม้ว่าจะไม่มีการเรียกไปยังpthread_call_signalหรือpthread_cond_broadcastบนเงื่อนไข
• เธรดที่ถูกบล็อกด้วยการpthread_cond_waitส่งคืนเนื่องจากการเรียกไปยังpthread_cond_signalหรือpthread_cond_broadcastอย่างไรก็ตามหลังจากการเรียกใช้ mutex อีกครั้งพบว่าเพรดิเคตพื้นฐานไม่เป็นจริงอีกต่อไป

แต่กรณีหลังสามารถเกิดขึ้นได้แม้ว่าการใช้งานตัวแปรเงื่อนไขจะไม่อนุญาตให้เป็นกรณีแรก พิจารณาคิวการบริโภคของผู้ผลิตและสามเธรด

• เธรด 1 เพิ่ง dequeued องค์ประกอบและปล่อย mutex และตอนนี้คิวว่างเปล่า เธรดกำลังทำสิ่งที่มันทำกับองค์ประกอบที่ได้มาบน CPU บางตัว
• เธรด 2 พยายามที่จะถอนออกจากองค์ประกอบ แต่พบว่าคิวนั้นว่างเปล่าเมื่อตรวจสอบภายใต้ mutex การโทรpthread_cond_waitและบล็อกในการโทรที่รอสัญญาณ / การออกอากาศ
• เธรด 3 รับ mutex แทรกอิลิเมนต์ใหม่เข้าในคิวแจ้งตัวแปรเงื่อนไขและปลดล็อก
• ในการตอบสนองต่อการแจ้งเตือนจากเธรด 3 เธรด 2 ซึ่งรออยู่บนเงื่อนไขถูกกำหนดเวลาให้รัน
• อย่างไรก็ตามก่อนที่เธรด 2 จะจัดการกับ CPU และคว้าการล็อกคิวเธรด 1 จะเสร็จสิ้นภารกิจปัจจุบันและกลับไปที่คิวเพื่อทำงานมากขึ้น มันได้รับการล็อคคิวตรวจสอบภาคและพบว่ามีการทำงานในคิว มันดำเนินการเพื่อถอนคิวไอเท็มที่เธรด 3 แทรกปลดล็อกและทำสิ่งที่มันทำกับไอเท็มที่เธรด 3 เข้าคิว
• ตอนนี้เธรด 2 ขึ้นบน CPU และรับการล็อก แต่เมื่อตรวจสอบเพรดิเคตพบว่าคิวนั้นว่างเปล่า หัวข้อที่ 1 'ขโมย' รายการดังนั้นการปลุกจะดูเหมือนเป็นของปลอม เธรด 2 จำเป็นต้องรอเงื่อนไขอีกครั้ง

ดังนั้นเนื่องจากคุณจำเป็นต้องตรวจสอบเพรดิเคตภายใต้การวนซ้ำอยู่เสมอดังนั้นจึงไม่แตกต่างกันหากตัวแปรเงื่อนไขพื้นฐานสามารถมีการปลุกซ้ำ ๆ ประเภทอื่นได้

ส่วน "การกระตุ้นหลายครั้งโดยสัญญาณสภาพ" ในpthread_cond_signalมีตัวอย่างการนำไปปฏิบัติของ pthread_cond_wait และ pthread_cond_signal ซึ่งเกี่ยวข้องกับการปลุกปลอม

ในขณะที่ฉันไม่คิดว่ามันได้รับการพิจารณาในขณะออกแบบนี่คือเหตุผลทางเทคนิคจริง: เมื่อใช้ร่วมกับการยกเลิกเธรดมีเงื่อนไขที่ใช้ตัวเลือกในการปลุก "เก๊บ" อาจมีความจำเป็นอย่างน้อยเว้นแต่คุณ ยินดีที่จะกำหนดข้อ จำกัด ที่แข็งแกร่งมาก ๆ เกี่ยวกับกลยุทธ์การดำเนินการที่เป็นไปได้

ปัญหาที่สำคัญคือถ้าเธรดทำงานในการยกเลิกในขณะที่ถูกบล็อกในpthread_cond_waitผลข้างเคียงจะต้องเหมือนกับว่ามันไม่ได้ใช้สัญญาณใด ๆ กับตัวแปรเงื่อนไข อย่างไรก็ตามมันเป็นเรื่องยาก (และมีข้อ จำกัด อย่างมาก) เพื่อให้แน่ใจว่าคุณยังไม่ได้บริโภคสัญญาณเมื่อคุณเริ่มทำการยกเลิกและในขั้นตอนนี้อาจเป็นไปไม่ได้ที่จะ "โพสต์ใหม่" สัญญาณไปยังตัวแปรเงื่อนไขเนื่องจากคุณอาจ อยู่ในสถานการณ์ที่ผู้โทรเข้ามาpthread_cond_signalได้พิสูจน์แล้วว่าได้ทำลาย condvar และปลดปล่อยหน่วยความจำที่มันอาศัยอยู่

ค่าเผื่อการปลุกลวงจะช่วยให้คุณออกได้ง่าย แทนที่จะดำเนินการยกเลิกต่อไปเมื่อมาถึงในขณะที่บล็อกตัวแปรเงื่อนไขหากคุณใช้สัญญาณไปแล้ว (หรือหากคุณต้องการที่จะขี้เกียจไม่ว่าจะเกิดอะไรขึ้น) คุณสามารถประกาศการปลุกปลอมที่เกิดขึ้นแทนได้ และกลับมาพร้อมกับความสำเร็จ สิ่งนี้ไม่รบกวนการทำงานของการยกเลิกเนื่องจากผู้โทรที่ถูกต้องจะทำการยกเลิกที่ค้างอยู่ในครั้งถัดไปที่ลูปและโทรpthread_cond_waitอีกครั้ง