ایک race condition ایک ایسا bug ہے جہاں نتیجہ shared state تک رسائی کرنے والے concurrent operations کی غیر متوقع timing پر منحصر ہوتا ہے۔ کلاسیکی صورت ایک 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 میں پاس ہو جاتے ہیں اور load کے تحت ناکام ہوتے ہیں۔ یہ اُس وقت تک چھپے رہتے ہیں جب تک timing نہ بدلے — ایک تیز تر machine، زیادہ traffic، ایک نیا core۔ shared mutable state کو بنیادی وجہ کے طور پر پہچاننا پہلا قدم ہے؛ interviewers دیکھنا چاہتے ہیں کہ آپ غیر محفوظ read-modify-write کو پکڑ سکتے ہیں۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں