race condition क्यों होती है, और जो सिर्फ प्रोडक्शन में दिखती है उसे आप कैसे ढूंढते हैं?

race condition तब होती है जब दो threads या requests एक ही shared mutable state को छूते हैं और नतीजा timing पर टिक जाता है। इसका क्लासिक रूप है read, modify, write, वह भी तीनों steps पर lock पकड़े बिना। प्रोडक्शन में इसे ढूंढने के लिए ऐसी state देखिए जिसे पहले चेक किया जाता है और फिर उस पर काम होता है, उस क्रम के आसपास correlated logging लगाइए, unit test के बजाय असली concurrency में उसे दोबारा पैदा कीजिए, और डेटाबेस के constraints को उल्लंघन पकड़ने दीजिए।

race के लिए दो चीजें चाहिए: shared mutable state, और दो रास्ते जो एक ही वक्त उस तक पहुंचें। मैंने जितनी भी डिबग की हैं, लगभग सबकी शक्ल एक ही है, एक चेक और उसके बाद एक action, और बीच में एक खाली जगह। balance पढ़ो, तय करो कि काफी है, नया balance लिखो। दो requests आपस में गुंथ जाती हैं और नंबर गलत निकलता है। प्रोडक्शन में इन्हें ढूंढना ज्यादातर इस बात को मान लेने पर टिका है कि आप क्लिक करके repro तक नहीं पहुंच सकते। मैं एक स्क्रिप्ट लिखता हूं जो वही request दो सौ बार एक साथ भेजती है, क्योंकि खिड़की शायद दो मिलीसेकंड चौड़ी हो। फिर मैं read और write के दोनों तरफ request id के साथ लॉग करता हूं, ताकि टाइमलाइन में गुंथाव दिख जाए। फिक्स के लिए मैं invariant को ऐप से हटाकर डेटाबेस में ले जाने की कोशिश करता हूं: अपेक्षित वैल्यू पर where clause वाला update, या एक unique constraint, ताकि डेटाबेस ही उसे लागू करे। एप्लिकेशन लेवल के locks तभी काम करते हैं जब हर लिखने वाला आपके कोड से गुजरे, और कभी न कभी कोई नहीं गुजरेगा।