Race condition हा एक bug आहे जिथे निकाल shared state ला access करणाऱ्या concurrent operations च्या अनिश्चित timing वर अवलंबून असतो. classic प्रकरण म्हणजे 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
यावरचा उपाय म्हणजे एका 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. Shared mutable state हेच मूळ कारण आहे हे ओळखणे हे पहिले पाऊल आहे; interviewers ना तुम्ही असुरक्षित read-modify-write ओळखताना पाहायचे असते.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या