मेरी राय में, यह एक शानदार साक्षात्कार प्रश्न है - कम से कम यह मानकर (1) उम्मीदवार को थ्रेडिंग का गहरा ज्ञान होने की उम्मीद है, और (2) साक्षात्कारकर्ता को भी गहन ज्ञान है और उम्मीदवार की जांच करने के लिए प्रश्न का उपयोग कर रहा है। यह हमेशा संभव है कि साक्षात्कारकर्ता एक विशिष्ट, संकीर्ण उत्तर की तलाश में था, लेकिन एक सक्षम साक्षात्कारकर्ता को निम्नलिखित की तलाश में होना चाहिए:
- ठोस कार्यान्वयन से अमूर्त अवधारणाओं को अलग करने की क्षमता। मैं इसे मुख्य रूप से कुछ टिप्पणियों पर मेटा-टिप्पणी के रूप में फेंकता हूं। नहीं, इस तरह से शब्दों की एकल सूची को संसाधित करने का कोई मतलब नहीं है। हालांकि, संचालन की एक पाइपलाइन की अमूर्त अवधारणा, जिसमें विभिन्न क्षमताओं की कई मशीनें हो सकती हैं, महत्वपूर्ण है।
- मेरे अनुभव में (वितरित, बहु-प्रक्रिया और बहु-थ्रेडेड अनुप्रयोगों के लगभग 30 वर्ष), काम का वितरण करना कठिन हिस्सा नहीं है। परिणामों को इकट्ठा करना और स्वतंत्र प्रक्रियाओं का समन्वय करना जहां अधिकांश थ्रेडिंग बग होते हैं (फिर से, मेरे अनुभव में)। समस्या को एक साधारण श्रृंखला तक नीचे ले जाकर, साक्षात्कारकर्ता यह देख सकता है कि उम्मीदवार समन्वय के बारे में कितना अच्छा सोचते हैं। साथ ही, साक्षात्कारकर्ता के पास सभी प्रकार के फॉलो-ऑन प्रश्न पूछने का अवसर है, जैसे "ठीक है, क्या होगा यदि प्रत्येक थ्रेड को पुनर्निर्माण के लिए अपने शब्द को दूसरे धागे पर भेजना है।"
- क्या उम्मीदवार सोचता है कि प्रोसेसर का मेमोरी मॉडल कार्यान्वयन को कैसे प्रभावित कर सकता है? यदि एक ऑपरेशन के परिणाम कभी भी L1 कैश से फ्लश नहीं होते हैं, तो यह एक बग है, भले ही कोई स्पष्ट सहमति न हो।
- क्या उम्मीदवार आवेदन तर्क से अलग है?
यह अंतिम बिंदु, मेरी राय में, सबसे महत्वपूर्ण है। फिर से, मेरे अनुभव के आधार पर, थ्रेडेड कोड को डीबग करना अधिक कठिन हो जाता है यदि थ्रेडिंग को एप्लिकेशन लॉजिक के साथ मिलाया जाता है (उदाहरण के लिए SO पर सभी स्विंग प्रश्नों को देखें)। मेरा मानना है कि स्पष्ट रूप से परिभाषित हैंडऑफ़ के साथ सबसे अच्छा बहु-थ्रेडेड कोड स्व-निहित एकल-थ्रेडेड कोड के रूप में लिखा गया है।
इसे ध्यान में रखते हुए, मेरा दृष्टिकोण प्रत्येक थ्रेड को दो कतार देना होगा: एक इनपुट के लिए, एक आउटपुट के लिए। इनपुट कतार पढ़ते समय थ्रेड ब्लॉक हो जाता है, पहले शब्द को स्ट्रिंग से हटा देता है, और स्ट्रिंग के शेष भाग को अपनी आउटपुट कतार में भेज देता है। इस दृष्टिकोण की कुछ विशेषताएं:
- एप्लिकेशन कोड एक कतार पढ़ने, डेटा के लिए कुछ करने और कतार लिखने के लिए ज़िम्मेदार है। यह परवाह नहीं करता है कि यह बहु-थ्रेडेड है या नहीं, या कतार एक मशीन पर इन-मेमोरी कतार है या दुनिया के विपरीत किनारों पर रहने वाली मशीनों के बीच एक टीसीपी-आधारित कतार है।
- क्योंकि एप्लिकेशन कोड को एकल-थ्रेडेड के रूप में लिखा गया है, यह बहुत अधिक मचान की आवश्यकता के बिना निर्धारक तरीके से परीक्षण करने योग्य है।
- निष्पादन के अपने चरण के दौरान, एप्लिकेशन कोड संसाधित होने वाले स्ट्रिंग का मालिक है। इसे समवर्ती-निष्पादित थ्रेड्स के साथ सिंक्रनाइज़ेशन के बारे में परवाह नहीं है।
उस ने कहा, अभी भी बहुत सारे ग्रे क्षेत्र हैं जो एक सक्षम साक्षात्कारकर्ता जांच कर सकते हैं:
- "ठीक है, लेकिन हम संगामिति आदिम के अपने ज्ञान को देखने के लिए देख रहे हैं? क्या आप एक अवरुद्ध कतार को लागू कर सकते हैं?" आपका पहला जवाब, निश्चित रूप से, यह होना चाहिए कि आप अपनी पसंद के मंच से एक पूर्व-निर्मित अवरुद्ध कतार का उपयोग करेंगे। हालाँकि, यदि आप थ्रेड्स को समझते हैं, तो आप कोड के एक दर्जन लाइनों के तहत एक कतार कार्यान्वयन बना सकते हैं, जो आपके प्लेटफ़ॉर्म का समर्थन करता है जो भी सिंक्रनाइज़ेशन प्राइमेटिव का उपयोग करता है।
- "क्या होगा अगर प्रक्रिया में एक कदम बहुत लंबा समय लगता है?" आपको इस बारे में सोचना चाहिए कि क्या आप एक बंधी हुई या अनबाउंड आउटपुट कतार चाहते हैं, यदि आप त्रुटियों को संभाल सकते हैं, और यदि आपके पास देरी है, तो समग्र थ्रूपुट पर प्रभाव।
- कैसे स्रोत स्ट्रिंग को कुशलता से संलग्न करना है। जरूरी नहीं कि अगर आप इन-मेमरी कतारों से निपट रहे हों तो एक समस्या है, लेकिन अगर आप मशीनों के बीच जा रहे हैं तो यह एक समस्या हो सकती है। आप एक अंतर्निहित अपरिवर्तनीय बाइट सरणी के शीर्ष पर केवल-पढ़ने के लिए रैपर भी देख सकते हैं।
अंत में, यदि आपके पास समवर्ती प्रोग्रामिंग का अनुभव है, तो आप कुछ फ्रेमवर्क (जैसे, जावा / स्काला के लिए अक्का) के बारे में बात कर सकते हैं जो पहले से ही इस मॉडल का पालन करते हैं।