Race condition एउटा bug हो जहाँ नतिजा साझा state access गर्ने समवर्ती operations को अप्रत्याशित timing मा निर्भर हुन्छ। क्लासिक अवस्था atomic नभएको read-modify-write हो।
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 मा पास हुन्छन् र load मा fail हुन्छन्। तिनीहरू timing नबदलिएसम्म लुक्छन् — छिटो machine, बढी traffic, नयाँ core। साझा mutable state लाई मूल कारणका रूपमा चिन्नु पहिलो कदम हो; interviewers ले तपाईंले असुरक्षित read-modify-write भेट्न सक्ने देख्न चाहन्छन्।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्