जब कई threads data साझा करते हैं, तो उनके operations किसी बहु-चरणीय update के बीचोंबीच interleave हो सकते हैं, जिससे एक race condition पैदा होती है — एक ऐसा bug जिसका परिणाम अप्रत्याशित timing पर निर्भर करता है। Synchronization वह उपकरण-समूह है जो सुरक्षित क्रम को बाध्य करता है।
count++ atomic दिखता है पर असल में read-modify-write है:
// two threads, shared int count = 0, each does count++ once
// thread A: read count (0) ─┐ interleaving loses an update:
// thread B: read count (0) ─┤ both read 0, both write 1 → count == 1, not 2
// thread A: write 1 │
// thread B: write 1 ┘
पढ़ने और लिखने के बीच की खिड़की एक critical section है — वह code जो साझा state को छूता है और concurrently नहीं चलना चाहिए।
pthread_mutex_lock(&m);
count++; // critical section — exclusive
pthread_mutex_unlock(&m);
Locks races हल करते हैं पर नए जोखिम लाते हैं: deadlock (threads एक-दूसरे के locks पर प्रतीक्षा करते हुए), priority inversion, और contention (threads serialize हो जाते हैं, parallelism को मार देते हैं)। अंगूठे का नियम: critical sections को छोटा रखें, और कई locks को हमेशा एक सुसंगत global क्रम में acquire करें।
Concurrency bugs खोजने में सबसे कठिन में से हैं — वे nondeterministic होते हैं और अक्सर debugger के नीचे गायब हो जाते हैं। Interviewers यह देखना चाहते हैं कि आप एक critical section को पहचान सकते हैं, सही primitive चुन सकते हैं (mutex बनाम semaphore बनाम atomic), और failure modes (deadlock, contention) पर तर्क कर सकते हैं। यह किसी भी multithreaded server, shared cache, या counter पर सीधे लागू होता है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें