2011-12-21 23 views
104

आदमी पेज के शब्दों में:pthread_cond_wait में नकली wakeups क्यों हैं?

हालत चरों का उपयोग करते वहाँ हमेशा एक बूलियन साझा प्रत्येक शर्त प्रतीक्षा यह सच है अगर धागा आगे बढ़ना चाहिए के साथ जुड़े चर शामिल विधेय है। Pthread_cond_timedwait() या pthread_cond_wait() फ़ंक्शंस से नकली wakeups हो सकता है। चूंकि pthread_cond_timedwait() या pthread_cond_wait() से वापसी इस predicate के मूल्य के बारे में कुछ भी नहीं दर्शाती है, इस तरह के रिटर्न पर भविष्यवाणी का फिर से मूल्यांकन किया जाना चाहिए।

तो, pthread_cond_wait वापस लौटा सकता है अगर आपने इसे संकेत नहीं दिया है। कम से कम पहली नज़र में, यह बहुत अत्याचारी लगता है। यह एक ऐसे फ़ंक्शन की तरह होगा जो गलत मूल्य को यादृच्छिक रूप से वापस कर देता है या वास्तव में उचित वापसी कथन तक पहुंचने से पहले यादृच्छिक रूप से लौटाया जाता है। यह एक प्रमुख बग की तरह लगता है। लेकिन तथ्य यह है कि उन्होंने इसे ठीक करने के बजाए मैन पेज में दस्तावेज करने के लिए चुना है, ऐसा लगता है कि एक वैध कारण है कि pthread_cond_wait तेजी से जागने के लिए समाप्त होता है। संभवतः, यह कैसे काम करता है इसके बारे में कुछ अंतर्निहित है जो इसे बनाता है ताकि इसकी सहायता नहीं की जा सके। सवाल क्या है।

क्योंpthread_cond_wait नकली वापसी करता है? यह गारंटी क्यों नहीं दे सकता है कि यह ठीक से संकेतित होने पर ही जागने जा रहा है? क्या कोई इसके नकली व्यवहार के कारण को समझा सकता है?

+4

मुझे लगता है कि जब भी प्रक्रिया सिग्नल पकड़ लेती है तो उसे लौटने के साथ कुछ करना पड़ता है। सिग्नल इंटरप्ट होने के बाद अधिकांश * निक्सेस अवरुद्ध कॉल को पुनरारंभ नहीं करते हैं; वे सिर्फ एक त्रुटि कोड सेट/वापस करते हैं जो कहते हैं कि एक संकेत हुआ। – cHao

+0

@cHao: हालांकि ध्यान दें कि क्योंकि कंडीशन चर के पास * अन्य * नकली वेक-अप के कारण हैं, सिग्नल को संभालना 'pthread_cond_ (timed) प्रतीक्षा' के लिए कोई त्रुटि नहीं है: "अगर सिग्नल वितरित किया जाता है ... थ्रेड कंडीशन वैरिएबल के लिए इंतजार करना शुरू कर देता है जैसे कि यह बाधित नहीं हुआ था, या यह नकली wakeup के कारण शून्य वापस आ जाएगा "। सिग्नल द्वारा बाधित होने पर अन्य अवरुद्ध कार्य 'EINTR' इंगित करते हैं (उदा।' Read'), या फिर से शुरू करने की आवश्यकता होती है (उदा। 'Pthread_mutex_lock')। तो अगर नकली जागने के लिए कोई अन्य कारण नहीं थे, तो 'pthread_cond_wait' को इनमें से किसी एक की तरह परिभाषित किया जा सकता था। –

+3

विकिपीडिया पर एक संबंधित लेख: [नकली wakeup] (http://en.wikipedia.org/wiki/Spurious_wakeup) – Palec

उत्तर

64

निम्नलिखित विवरण "Programming with POSIX Threads" (पी 80।) में डेविड आर Butenhof द्वारा दिया जाता है:

नकली wakeups अजीब लग सकता है, लेकिन कुछ मल्टीप्रोसेसर प्रणाली, हालत Wakeup पूरी तरह से उम्मीद के मुताबिक काफी हद तक सभी हालत धीमी गति से हो सकता है बनाने के लिए परिवर्तनीय संचालन।

निम्नलिखित comp.programming.threads discussion में उन्होंने डिजाइन के पीछे की सोच पर फैलता:

 
Patrick Doyle wrote: 
> In article , Tom Payne wrote: 
> >Kaz Kylheku wrote: 
> >: It is so because implementations can sometimes not avoid inserting 
> >: these spurious wakeups; it might be costly to prevent them. 

> >But why? Why is this so difficult? For example, are we talking about 
> >situations where a wait times out just as a signal arrives? 

> You know, I wonder if the designers of pthreads used logic like this: 
> users of condition variables have to check the condition on exit anyway, 
> so we will not be placing any additional burden on them if we allow 
> spurious wakeups; and since it is conceivable that allowing spurious 
> wakeups could make an implementation faster, it can only help if we 
> allow them. 

> They may not have had any particular implementation in mind. 

You're actually not far off at all, except you didn't push it far enough. 

The intent was to force correct/robust code by requiring predicate loops. This was 
driven by the provably correct academic contingent among the "core threadies" in 
the working group, though I don't think anyone really disagreed with the intent 
once they understood what it meant. 

We followed that intent with several levels of justification. The first was that 
"religiously" using a loop protects the application against its own imperfect 
coding practices. The second was that it wasn't difficult to abstractly imagine 
machines and implementation code that could exploit this requirement to improve 
the performance of average condition wait operations through optimizing the 
synchronization mechanisms. 
/------------------[ [email protected] ]------------------\ 
| Compaq Computer Corporation    POSIX Thread Architect | 
|  My book: http://www.awl.com/cseng/titles/0-201-63392-2/  | 
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/ 

75

वहाँ रहे हैं कम से कम दो बातें 'नकली Wakeup' अर्थ हो सकता है:

  • एक सूत्र में अवरुद्ध pthread_cond_wait कॉल से वापस आ सकता है भले ही इस शर्त पर सिग्नल या प्रसारण करने के लिए कोई कॉल नहीं हुआ।
  • सिग्नल या प्रसारण के लिए कॉल के कारण pthread_cond_wait रिटर्न में अवरुद्ध एक धागा, हालांकि म्यूटेक्स को पुनः प्राप्त करने के बाद अंतर्निहित भविष्य अब सत्य नहीं पाया जाता है।

लेकिन बाद का मामला तब भी हो सकता है जब स्थिति परिवर्तनीय कार्यान्वयन पूर्व मामले की अनुमति नहीं देता है। एक निर्माता उपभोक्ता कतार, और तीन धागे पर विचार करें।

  • थ्रेड 1 ने सिर्फ एक तत्व को हटा दिया है और म्यूटेक्स जारी किया है, और कतार अब खाली है। धागा कुछ सीपीयू पर प्राप्त तत्व के साथ जो भी करता है वह कर रहा है।
  • थ्रेड 2 तत्व को निकालने का प्रयास करता है, लेकिन म्यूटेक्स के तहत चेक किए जाने पर कतार खाली होने पर, pthread_cond_wait को कॉल करता है, और कॉल में ब्लॉक सिग्नल/प्रसारण की प्रतीक्षा करता है।
  • थ्रेड 3 म्यूटेक्स प्राप्त करता है, कतार में एक नया तत्व डालता है, हालत परिवर्तनीय को सूचित करता है, और लॉक जारी करता है।
  • थ्रेड 3 से अधिसूचना के जवाब में, थ्रेड 2, जो स्थिति पर इंतजार कर रहा था, चलाने के लिए निर्धारित है।
  • हालांकि थ्रेड 2 सीपीयू पर पहुंचने और कतार लॉक को पकड़ने से पहले, थ्रेड 1 अपने वर्तमान कार्य को पूरा करता है, और अधिक काम के लिए कतार में लौटता है। यह कतार लॉक प्राप्त करता है, भविष्यवाणी करता है, और पाया जाता है कि कतार में काम है। यह उस आइटम को हटाने के लिए आगे बढ़ता है जो थ्रेड 3 डाला जाता है, लॉक जारी करता है, और जो कुछ भी करता है वह उस थ्रेड 3 के साथ करता है जो थ्रेड 3 लगाया जाता है।
  • थ्रेड 2 अब एक सीपीयू पर आता है और लॉक प्राप्त करता है, लेकिन जब यह भविष्यवाणी करता है, तो यह पता चलता है कि कतार खाली है। थ्रेड 1 'आइटम चुरा लिया', तो जागरूकता नकली प्रतीत होता है। थ्रेड 2 को फिर से स्थिति पर इंतजार करने की जरूरत है।

इसलिए चूंकि आपको पहले से ही हमेशा एक लूप के नीचे भविष्य की जांच करने की आवश्यकता होती है, इसलिए अंतर्निहित स्थिति चर के अन्य प्रकार के नकली वेकअप होने पर इससे कोई फर्क नहीं पड़ता है।

+13

हां। अनिवार्यता, यह तब होता है जब एक घटना के साथ एक सिंक्रनाइज़ेशन तंत्र के बजाय एक घटना का उपयोग किया जाता है। अफसोस की बात है, ऐसा लगता है कि POSIX semaphores, (वैसे भी लिनक्स पर), spurius wakeups के अधीन भी हैं। मुझे बस थोड़ा अजीब लगता है कि सिंक्रनाइज़ेशन प्राइमेटिव्स की मौलिक कार्यक्षमता विफलता को केवल 'सामान्य' के रूप में स्वीकार किया जाता है और इसे उपयोगकर्ता स्तर पर चारों ओर काम करना पड़ता है :(संभवतः, डेवलपर्स को सिस्टम कॉल होने पर हथियारों में रखा जाएगा 0 'स्पिरियस सेगफॉल्ट' सेक्शन, या शायद 'गलत यूआरएल से जुड़ा हुआ नकली' या 'गलत फाइल का नकली खुलना'। –

+1

ऊपर से साफ़, बहुत स्पष्ट। – Alcott

+2

"नकली wakeupup" का अधिक आम परिदृश्य सबसे अधिक संभावना है - pthread_cond_broadcast() के लिए कॉल का प्रभाव। मान लीजिए कि आपके पास 5 धागे का पूल है, दो प्रसारण तक जागते हैं और काम करते हैं। अन्य तीन जागते हैं और काम मिलते हैं। मल्टी प्रोसेसर सिस्टम भी नतीजतन एक सशर्त सिग्नल दुर्घटना से कई धागे जागता है। कोड सिर्फ भविष्यवाणी की जांच करता है, एक अमान्य स्थिति देखता है, और सोने के लिए वापस चला जाता है। किसी भी मामले में, भविष्यवाणी की जांच समस्या हल करती है। आम तौर पर, आईएमओ कच्चे POSIX म्यूटेक्स और सशर्त का उपयोग नहीं करना चाहिए। – CubicleSoft

6

pthread_cond_signal में "कंडीशन सिग्नल द्वारा एकाधिक जागरूकता" में pthread_cond_wait और pthread_cond_signal का एक उदाहरण कार्यान्वयन है जिसमें नकली wakekups शामिल हैं।

+1

मुझे लगता है कि यह उत्तर गलत है, जहां तक ​​यह जाता है। उस पृष्ठ पर नमूना कार्यान्वयन में "एक सूचित करें" का कार्यान्वयन है जो "सभी को सूचित करें" के बराबर है; लेकिन यह वास्तव में * नकली * wakeups उत्पन्न नहीं लगता है। एक थ्रेड के लिए जागने का एकमात्र तरीका किसी अन्य धागे द्वारा "सभी को सूचित करें", या किसी अन्य धागे द्वारा "चीज़ को सूचित करने" - जो वास्तव में है- "सभी को सूचित करें" का आह्वान करते हैं। – Quuxplusone

संबंधित मुद्दे