एक race condition एक ऐसा bug है जहाँ परिणाम साझा state तक पहुँचने वाले समवर्ती operations के अप्रत्याशित timing पर निर्भर करता है। classic मामला एक read-modify-write है जो atomic नहीं है।
counter += 1 atomic दिखता है पर वास्तव में तीन चरण हैं: read, add, write। दो threads इस तरह interleave हो सकते हैं कि एक update खो जाए।
counter = 0
Thread A: read 0 ─────────── write 1
Thread B: read 0 ─ write 1
Result: 1 (should be 2 — one increment lost)
counter = 0
def inc():
global counter
for _ in range(100_000):
counter += 1 # NOT atomic: read, +1, write
# Run two threads, expect 200_000...
# ...but you often get less — a lost update
समाधान है section को एक lock के साथ atomic बनाना:
lock = threading.Lock()
def inc():
global counter
for _ in range(100_000):
with lock: # only one thread in here at a time
counter += 1
लक्षण ही races को खतरनाक बनाता है: रुक-रुक कर, गैर-पुनरुत्पादनीय गलत परिणाम जो tests में pass होते हैं और load के तहत fail होते हैं। वे तब तक छिपे रहते हैं जब तक timing न बदले — एक तेज़ मशीन, अधिक traffic, एक नया core। साझा mutable state को मूल कारण के रूप में पहचानना पहला कदम है; interviewers आपको असुरक्षित read-modify-write को पकड़ते देखना चाहते हैं।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें