புரோகிராமர்கள் மற்றும் பொறியாளர்களின் நாட்டுப்புறக் கதைகள் (பகுதி 1)

பிழைகள் சில சமயங்களில் முற்றிலும் நம்பமுடியாத வெளிப்பாடுகளை எவ்வாறு கொண்டிருக்கின்றன என்பதைப் பற்றிய இணையத்திலிருந்து வரும் கதைகளின் தேர்வு இது. ஒருவேளை உங்களுக்கும் ஏதாவது சொல்லலாம்.

வெண்ணிலா ஐஸ்கிரீமுக்கு கார் அலர்ஜி

எப்பொழுதும் வெளிப்படையானது பதில் இல்லை என்பதையும், உண்மைகள் எவ்வளவு தூரமானதாகத் தோன்றினாலும், அவை இன்னும் உண்மைகள் என்பதையும் புரிந்துகொள்ளும் பொறியாளர்களுக்கான கதை. ஜெனரல் மோட்டார்ஸ் கார்ப்பரேஷனின் போண்டியாக் பிரிவுக்கு ஒரு புகார் வந்தது:

இது இரண்டாவது முறையாக நான் உங்களுக்கு எழுதுகிறேன், பதிலளிக்காததற்காக நான் உங்களைக் குறை கூறவில்லை, ஏனென்றால் அது பைத்தியமாகத் தெரிகிறது. எங்கள் குடும்பத்தில் தினமும் இரவு உணவுக்குப் பிறகு ஐஸ்கிரீம் சாப்பிடுவது வழக்கம். ஒவ்வொரு முறையும் ஐஸ்கிரீம் வகைகள் மாறுகின்றன, இரவு உணவிற்குப் பிறகு, முழு குடும்பமும் எந்த ஐஸ்கிரீமை வாங்க வேண்டும் என்பதைத் தேர்வுசெய்கிறது, அதன் பிறகு நான் கடைக்குச் செல்கிறேன். நான் சமீபத்தில் ஒரு புதிய போண்டியாக் வாங்கினேன், அதன் பிறகு ஐஸ்கிரீம் பெறுவதற்கான எனது பயணங்கள் ஒரு பிரச்சனையாக மாறியது. ஒவ்வொரு முறை வெண்ணிலா ஐஸ்கிரீம் வாங்கிக் கடையிலிருந்து வரும்போதும் கார் ஸ்டார்ட் ஆகாது. வேறு ஏதாவது ஐஸ்கிரீம் கொண்டு வந்தால், எந்த பிரச்சனையும் இல்லாமல் கார் ஸ்டார்ட் ஆகிறது. நான் ஒரு தீவிரமான கேள்வியைக் கேட்க விரும்புகிறேன், அது எவ்வளவு முட்டாள்தனமாகத் தோன்றினாலும்: "நான் வெண்ணிலா ஐஸ்கிரீம் கொண்டு வரும்போது அது தொடங்காமல், மற்றொரு சுவையான ஐஸ்கிரீமைக் கொண்டு வரும்போது எளிதாகத் தொடங்கும் போன்டியாக் பற்றி என்ன?" "

நீங்கள் நினைப்பது போல், பிரிவுத் தலைவர் கடிதம் குறித்து சந்தேகம் கொண்டிருந்தார். இருப்பினும், நான் ஒரு பொறியாளரை சோதனைக்கு அனுப்பினேன். ஒரு அழகான பகுதியில் வசிக்கும் ஒரு பணக்கார, நன்கு படித்த மனிதர் தன்னை சந்தித்தது அவருக்கு ஆச்சரியமாக இருந்தது. இருவரும் ஐஸ்கிரீம் சாப்பிடுவதற்காக கடைக்குச் செல்லலாம் என்று இரவு உணவுக்குப் பிறகு உடனடியாக சந்திக்க ஒப்புக்கொண்டனர். அன்று மாலை வெண்ணிலா, அவர்கள் காரில் திரும்பியதும் அது ஸ்டார்ட் ஆகவில்லை.

இன்னும் மூன்று மாலை பொறியாளர் வந்தார். முதல் முறையாக ஐஸ்கிரீம் சாக்லேட். கார் ஸ்டார்ட் ஆனது. இரண்டாவது முறை ஸ்ட்ராபெரி ஐஸ்கிரீம் இருந்தது. கார் ஸ்டார்ட் ஆனது. மூன்றாம் நாள் மாலை வெண்ணிலாவை எடுக்கச் சொன்னார். கார் ஸ்டார்ட் ஆகவில்லை.

பகுத்தறிவுப் பகுத்தறிந்து, பொறியாளர் காருக்கு வெண்ணிலா ஐஸ்கிரீமுக்கு ஒவ்வாமை இருப்பதாக நம்ப மறுத்துவிட்டார். எனவே, பிரச்சினைக்கு தீர்வு காணும் வரை அவர் தனது வருகையைத் தொடருவார் என்று காரின் உரிமையாளரிடம் ஒப்புக்கொண்டேன். வழியில், அவர் குறிப்புகளை எடுக்கத் தொடங்கினார்: அவர் அனைத்து தகவல்களையும், நாள் நேரம், பெட்ரோல் வகை, கடையில் இருந்து வருகை மற்றும் திரும்பும் நேரம் போன்றவற்றை எழுதினார்.

காரின் உரிமையாளர் வெண்ணிலா ஐஸ்கிரீம் வாங்குவதற்கு குறைந்த நேரத்தை செலவிட்டதை பொறியாளர் விரைவில் உணர்ந்தார். காரணம் கடையில் உள்ள பொருட்களின் அமைப்பு. வெண்ணிலா ஐஸ்கிரீம் மிகவும் பிரபலமானது மற்றும் அதை எளிதாகக் கண்டுபிடிக்கும் வகையில் கடையின் முன்புறத்தில் ஒரு தனி உறைவிப்பான் வைக்கப்பட்டது. மற்ற அனைத்து வகைகளும் கடையின் பின்புறத்தில் இருந்தன, மேலும் சரியான வகையைக் கண்டுபிடித்து பணம் செலுத்த அதிக நேரம் பிடித்தது.

இப்போது கேள்வி பொறியாளருக்கு இருந்தது: இயந்திரம் அணைக்கப்பட்ட தருணத்திலிருந்து குறைந்த நேரம் கடந்துவிட்டால் ஏன் கார் ஸ்டார்ட் ஆகவில்லை? பிரச்சனை நேரம் என்பதால், வெண்ணிலா ஐஸ்கிரீம் அல்ல, பொறியாளர் விரைவாக பதிலைக் கண்டுபிடித்தார்: அது ஒரு எரிவாயு பூட்டு. ஒவ்வொரு மாலையும் இது நிகழ்ந்தது, ஆனால் கார் உரிமையாளர் ஐஸ்கிரீமைத் தேடுவதற்கு அதிக நேரம் செலவழித்தபோது, ​​இயந்திரம் போதுமான அளவு குளிர்ச்சியடைந்து எளிதாகத் தொடங்கியது. அந்த மனிதன் வெண்ணிலா ஐஸ்கிரீம் வாங்கியபோது, ​​​​இன்ஜின் இன்னும் சூடாக இருந்தது மற்றும் எரிவாயு பூட்டைக் கரைக்க நேரம் இல்லை.

ஒழுக்கம்: முற்றிலும் பைத்தியக்காரத்தனமான பிரச்சினைகள் கூட சில நேரங்களில் உண்மையானவை.

விபத்தில் பெருச்சாளி

இதை அனுபவிப்பது வேதனையாக இருக்கிறது. ஒரு புரோகிராமராக, உங்கள் குறியீட்டை முதலில், இரண்டாவதாக, மூன்றாவது... எங்கோ பத்தாயிரமாவது இடத்தில் கம்பைலரைக் குற்றம் சொல்லப் பழகிக் கொள்கிறீர்கள். மேலும் பட்டியலில் நீங்கள் ஏற்கனவே உபகரணங்களைக் குறை கூறுகிறீர்கள்.

வன்பொருள் பிழை பற்றிய எனது கதை இங்கே.

க்ராஷ் பாண்டிகூட் விளையாட்டுக்காக, மெமரி கார்டில் ஏற்றுவதற்கும் சேமிப்பதற்கும் குறியீட்டை எழுதினேன். அத்தகைய ஸ்மக் கேம் டெவலப்பருக்கு, இது பூங்காவில் நடப்பது போல் இருந்தது: வேலை பல நாட்கள் ஆகும் என்று நினைத்தேன். இருப்பினும், நான் ஆறு வாரங்களுக்கு குறியீட்டை பிழைத்திருத்தத்தை முடித்தேன். வழியில், நான் மற்ற சிக்கல்களைத் தீர்த்தேன், ஆனால் ஒவ்வொரு சில நாட்களுக்கும் சில மணிநேரங்களுக்கு இந்த குறியீட்டிற்கு திரும்பினேன். வேதனையாக இருந்தது.

அறிகுறி இப்படித் தோன்றியது: நீங்கள் விளையாட்டின் தற்போதைய பிளேத்ரூவைச் சேமித்து, மெமரி கார்டை அணுகும்போது, ​​எல்லாமே கிட்டத்தட்ட எப்போதும் சரியாகிவிடும்... ஆனால் சில சமயங்களில் வெளிப்படையான காரணமின்றி படிக்கும் அல்லது எழுதும் செயல்பாட்டின் நேரம் முடிவடைகிறது. ஒரு குறுகிய பதிவு பெரும்பாலும் மெமரி கார்டை சேதப்படுத்தும். ஒரு வீரர் சேமிக்க முயற்சிக்கும்போது, ​​அவர் சேமிக்கத் தவறியது மட்டுமல்லாமல், வரைபடத்தையும் அழிக்கிறார். தனம்.

சிறிது நேரம் கழித்து, சோனியில் எங்கள் தயாரிப்பாளர், கோனி பஸ், பீதி அடைய ஆரம்பித்தார். இந்தப் பிழையுடன் விளையாட்டை எங்களால் அனுப்ப முடியவில்லை, ஆறு வாரங்களுக்குப் பிறகு என்ன பிரச்சனை என்று எனக்குப் புரியவில்லை. கோனி மூலம், நாங்கள் மற்ற PS1 டெவலப்பர்களைத் தொடர்பு கொண்டோம்: யாரேனும் இதைப் போன்றவற்றைச் சந்தித்திருக்கிறார்களா? இல்லை. மெமரி கார்டில் யாருக்கும் பிரச்சனை இல்லை.

பிழைத்திருத்தத்திற்கான யோசனைகள் உங்களிடம் இல்லாதபோது, ​​"பிரிந்து வெற்றிகொள்வது" மட்டுமே எஞ்சியிருக்கும் அணுகுமுறை: இன்னும் சிக்கலை ஏற்படுத்தும் ஒப்பீட்டளவில் சிறிய துண்டு இருக்கும் வரை, தவறான நிரலிலிருந்து மேலும் மேலும் குறியீட்டை அகற்றவும். அதாவது, பிழை உள்ள பகுதி இருக்கும் வரை நிரலை துண்டு துண்டாக துண்டிக்கிறீர்கள்.

ஆனால் விஷயம் என்னவென்றால், வீடியோ கேமிலிருந்து துண்டுகளை வெட்டுவது மிகவும் கடினம். ஈர்ப்பு விசையைப் பின்பற்றும் குறியீட்டை நீக்கிவிட்டால் அதை எப்படி இயக்குவது? அல்லது எழுத்துக்களை வரைவதா?

எனவே, முழு தொகுதிக்கூறுகளையும் பயனுள்ள ஒன்றைச் செய்வது போல் பாசாங்கு செய்யும் ஸ்டப்களுடன் மாற்ற வேண்டும், ஆனால் உண்மையில் பிழைகள் இல்லாத மிக எளிமையான ஒன்றைச் செய்ய வேண்டும். குறைந்த பட்சம் வேலை செய்ய விளையாட்டுக்கு இதுபோன்ற ஊன்றுகோல்களை எழுத வேண்டும். இது ஒரு மெதுவான மற்றும் வேதனையான செயல்முறையாகும்.

சுருக்கமாக, நான் அதை செய்தேன். விளையாட்டை இயக்க கணினியை உள்ளமைக்கும், ரெண்டரிங் வன்பொருளைத் தொடங்கும் ஆரம்பக் குறியீடு என்னிடம் இருக்கும் வரை மேலும் மேலும் குறியீட்டுத் துண்டுகளை அகற்றினேன். நிச்சயமாக, இந்த கட்டத்தில் என்னால் சேமிக்க மற்றும் ஏற்றும் மெனுவை உருவாக்க முடியவில்லை, ஏனென்றால் எல்லா கிராபிக்ஸ் குறியீட்டிற்கும் நான் ஒரு ஸ்டப்பை உருவாக்க வேண்டும். ஆனால் நான் (கண்ணுக்கு தெரியாத) சேவ் மற்றும் லோட் ஸ்கிரீனைப் பயன்படுத்தி ஒரு பயனராக நடிக்கலாம் மற்றும் சேமித்து பின்னர் மெமரி கார்டில் எழுதலாம்.

இது எனக்கு ஒரு சிறிய குறியீட்டை விட்டுச்சென்றது, அது இன்னும் மேலே உள்ள சிக்கலைக் கொண்டிருந்தது - ஆனால் அது இன்னும் தோராயமாக நடக்கிறது! பெரும்பாலும் எல்லாம் நன்றாக வேலை செய்தது, ஆனால் எப்போதாவது குறைபாடுகள் இருந்தன. நான் கிட்டத்தட்ட எல்லா கேம் குறியீட்டையும் அகற்றிவிட்டேன், ஆனால் பிழை இன்னும் உயிருடன் இருந்தது. இது புதிராக இருந்தது: மீதமுள்ள குறியீடு உண்மையில் எதையும் செய்யவில்லை.

ஒரு கட்டத்தில், அநேகமாக அதிகாலை மூன்று மணியளவில், எனக்கு ஒரு எண்ணம் தோன்றியது. படிக்கவும் எழுதவும் (உள்ளீடு/வெளியீடு) செயல்பாடுகள் துல்லியமான செயலாக்க நேரங்களை உள்ளடக்கியது. நீங்கள் ஹார்ட் டிரைவ், மெமரி கார்டு அல்லது புளூடூத் தொகுதியுடன் பணிபுரியும் போது, ​​வாசிப்பதற்கும் எழுதுவதற்கும் பொறுப்பான குறைந்த-நிலை குறியீடு கடிகார துடிப்புகளுக்கு ஏற்ப செயல்படுகிறது.

ஒரு கடிகாரத்தின் உதவியுடன், செயலியுடன் நேரடியாக இணைக்கப்படாத சாதனம் செயலியில் செயல்படும் குறியீட்டுடன் ஒத்திசைக்கப்படுகிறது. கடிகாரம் பாட் வீதத்தை தீர்மானிக்கிறது—தரவு அனுப்பப்படும் வேகம். நேரத்துடன் குழப்பம் இருந்தால், வன்பொருள் அல்லது மென்பொருள் அல்லது இரண்டும் குழப்பமடையும். இது மிகவும் மோசமானது, ஏனெனில் தரவு சேதமடையக்கூடும்.

நமது குறியீட்டில் உள்ள ஏதாவது நேரத்தைக் குழப்பினால் என்ன செய்வது? சோதனை நிரல் குறியீட்டில் இது தொடர்பான அனைத்தையும் நான் சரிபார்த்தேன், நாங்கள் நிரல்படுத்தக்கூடிய டைமரை PS1 முதல் 1 kHz (வினாடிக்கு 1000 உண்ணிகள்) அமைப்பதைக் கவனித்தேன். இது மிகவும் அதிகம்; முன்னிருப்பாக, கன்சோல் தொடங்கும் போது, ​​அது 100 ஹெர்ட்ஸ் வேகத்தில் இயங்கும். பெரும்பாலான விளையாட்டுகள் இந்த அதிர்வெண்ணைப் பயன்படுத்துகின்றன.

ஆண்டி, கேம் டெவலப்பர், டைமரை 1 kHz ஆக அமைக்கவும், இதனால் இயக்கங்கள் மிகவும் துல்லியமாக கணக்கிடப்படும். ஆண்டி அதிகமாகச் செல்ல முனைகிறார், மேலும் புவியீர்ப்பு விசையைப் பின்பற்றினால், அதை முடிந்தவரை துல்லியமாகச் செய்கிறோம்!

ஆனால் டைமரை விரைவுபடுத்துவது நிரலின் ஒட்டுமொத்த நேரத்தை எப்படியாவது பாதித்தால் என்ன செய்வது, எனவே மெமரி கார்டுக்கான பாட் வீதத்தை ஒழுங்குபடுத்தும் கடிகாரம்?

டைமர் குறியீட்டை நான் கருத்து தெரிவித்தேன். பிழை மீண்டும் நிகழவில்லை. ஆனால் நாங்கள் அதை சரிசெய்தோம் என்று இது அர்த்தப்படுத்துவதில்லை, ஏனென்றால் தோல்வி தோராயமாக ஏற்பட்டது. நான் அதிர்ஷ்டசாலியாக இருந்தால் என்ன செய்வது?

சில நாட்களுக்குப் பிறகு நான் சோதனைத் திட்டத்தை மீண்டும் பரிசோதித்தேன். பிழை மீண்டும் வரவில்லை. நான் முழு கேம் கோட்பேஸுக்குச் சென்று சேமித்தல் மற்றும் ஏற்றுதல் குறியீட்டை மாற்றியமைத்தேன், இதனால் மெமரி கார்டை அணுகுவதற்கு முன் நிரல்படுத்தக்கூடிய டைமர் அதன் அசல் மதிப்பிற்கு (100Hz) மீட்டமைக்கப்படும், பின்னர் மீண்டும் 1kHz க்கு மீட்டமைக்கும். மேலும் விபத்துக்கள் எதுவும் இல்லை.

ஆனால் இது ஏன் நடந்தது?

நான் மீண்டும் சோதனை திட்டத்திற்கு திரும்பினேன். 1 kHz டைமரில் பிழை ஏற்பட்டால் சில வடிவங்களைக் கண்டறிய முயற்சித்தேன். யாரோ ஒருவர் PS1 கட்டுப்படுத்தியுடன் விளையாடும்போது பிழை ஏற்படுவதை இறுதியில் நான் கவனித்தேன். இதை நானே அரிதாகவே செய்வேன் என்பதால் - சேவ் மற்றும் லோட் குறியீட்டைச் சோதிக்கும்போது எனக்கு ஏன் கட்டுப்படுத்தி தேவை? - இந்த சார்புநிலையை நான் கவனிக்கவில்லை. ஆனால் ஒரு நாள் எங்கள் கலைஞர்களில் ஒருவர் நான் சோதனையை முடிப்பதற்காகக் காத்திருந்தார் - நான் அந்த நேரத்தில் சபித்திருக்கலாம் - மேலும் பதட்டத்துடன் தனது கைகளில் உள்ள கட்டுப்படுத்தியை சுழற்றினார். தவறு நிகழ்ந்துவிட்டது. "பொறு, என்ன?!" சரி, மீண்டும் செய்!”

இந்த இரண்டு நிகழ்வுகளும் ஒன்றோடொன்று இணைந்திருப்பதை நான் உணர்ந்தபோது, ​​பிழையை எளிதாக மீண்டும் உருவாக்க முடிந்தது: நான் மெமரி கார்டில் பதிவு செய்ய ஆரம்பித்தேன், கட்டுப்படுத்தியை நகர்த்தி, மெமரி கார்டை அழித்துவிட்டேன். எனக்கு அது ஒரு வன்பொருள் பிழை போல் தோன்றியது.

நான் கோனிக்கு வந்து என் கண்டுபிடிப்பைப் பற்றி சொன்னேன். PS1 ஐ வடிவமைத்த பொறியாளர்களில் ஒருவருக்கு அவர் தகவலை தெரிவித்தார். "சாத்தியமற்றது," அவர் பதிலளித்தார், "இது ஒரு வன்பொருள் சிக்கலாக இருக்க முடியாது." எங்களுக்காக ஒரு உரையாடலை ஏற்பாடு செய்யும்படி கோனியிடம் கேட்டேன்.

பொறியாளர் என்னை அழைத்தார், நாங்கள் அவரது உடைந்த ஆங்கிலத்திலும் எனது (மிகவும்) உடைந்த ஜப்பானிய மொழியிலும் வாதிட்டோம். இறுதியாக நான் சொன்னேன், "கண்ட்ரோலரை நகர்த்துவது பிழையை ஏற்படுத்தும் எனது 30 வரி சோதனை திட்டத்தை அனுப்புகிறேன்." அவன் ஏற்றுக்கொண்டான். இது நேரத்தை வீணடிப்பதாகவும், அவர் ஒரு புதிய திட்டத்தில் மிகவும் பிஸியாக இருப்பதாகவும், ஆனால் நாங்கள் சோனியின் மிக முக்கியமான டெவலப்பர் என்பதால் விட்டுவிடுவதாகவும் கூறினார். எனது சோதனை திட்டத்தை சுத்தம் செய்து அவருக்கு அனுப்பினேன்.

அடுத்த நாள் மாலை (நாங்கள் லாஸ் ஏஞ்சல்ஸில் இருந்தோம், அவர் டோக்கியோவில் இருந்தார்) அவர் என்னை அழைத்து, வெட்கத்துடன் மன்னிப்பு கேட்டார். இது ஒரு வன்பொருள் பிரச்சனை.

பிழை என்னவென்று எனக்குத் தெரியவில்லை, ஆனால் சோனி தலைமையகத்தில் நான் கேட்டதிலிருந்து, நீங்கள் டைமரை அதிக மதிப்புக்கு அமைத்தால், அது டைமர் படிகத்திற்கு அருகில் உள்ள மதர்போர்டில் உள்ள கூறுகளில் குறுக்கிடுகிறது. அவற்றில் ஒன்று மெமரி கார்டுக்கான பாட் ரேட் கன்ட்ரோலர் ஆகும், இது கன்ட்ரோலர்களுக்கான பாட் வீதத்தையும் அமைத்தது. நான் ஒரு பொறியாளர் இல்லை, அதனால் நான் ஏதாவது குழப்பம் செய்திருக்கலாம்.

ஆனால் கீழே வரி என்னவென்றால், மதர்போர்டில் உள்ள கூறுகளுக்கு இடையில் குறுக்கீடு இருந்தது. கன்ட்ரோலர் போர்ட் மற்றும் மெமரி கார்டு போர்ட் மூலம் 1 கிலோஹெர்ட்ஸ் வேகத்தில் இயங்கும் டைமர் மூலம் ஒரே நேரத்தில் தரவை அனுப்பும்போது, ​​பிட்கள் தொலைந்து, தரவு தொலைந்து, கார்டு சேதமடைந்தது.

கெட்ட மாடுகள்

1980 களில், என் வழிகாட்டியான செர்ஜி SM-1800 க்கான மென்பொருளை எழுதினார், இது PDP-11 இன் சோவியத் குளோன் ஆகும். சோவியத் ஒன்றியத்தின் முக்கியமான போக்குவரத்து மையமான ஸ்வெர்ட்லோவ்ஸ்க் அருகே உள்ள ரயில் நிலையத்தில் இந்த மைக்ரோகம்ப்யூட்டர் இப்போது நிறுவப்பட்டுள்ளது. புதிய அமைப்பு வேகன்கள் மற்றும் சரக்கு போக்குவரத்தை வழிநடத்த வடிவமைக்கப்பட்டுள்ளது. ஆனால் அதில் ஒரு எரிச்சலூட்டும் பிழை இருந்தது, இது சீரற்ற செயலிழப்புகள் மற்றும் செயலிழப்புகளுக்கு வழிவகுத்தது. மாலையில் யாராவது வீட்டிற்குச் செல்லும்போது எப்போதும் வீழ்ச்சி ஏற்பட்டது. ஆனால் அடுத்த நாள் ஒரு முழுமையான விசாரணை இருந்தபோதிலும், கணினி அனைத்து கையேடு மற்றும் தானியங்கி சோதனைகளிலும் சரியாக வேலை செய்தது. இது பொதுவாக பந்தய நிலை அல்லது சில நிபந்தனைகளின் கீழ் ஏற்படும் வேறு சில போட்டிப் பிழையைக் குறிக்கிறது. இரவு தாமதமாக அழைப்புகள் சோர்வாக, செர்ஜி அதை கீழே பெற முடிவு, மற்றும் அனைத்து முதல், மார்ஷலிங் யார்டில் என்ன நிலைமைகள் கணினி செயலிழப்பு வழிவகுத்தது புரிந்து.

முதலில், அவர் விவரிக்கப்படாத அனைத்து நீர்வீழ்ச்சிகளின் புள்ளிவிவரங்களையும் சேகரித்து தேதி மற்றும் நேரத்தின் அடிப்படையில் ஒரு வரைபடத்தை உருவாக்கினார். முறை தெளிவாக இருந்தது. இன்னும் சில நாட்கள் கவனித்த பிறகு, எதிர்கால கணினி தோல்விகளின் நேரத்தை எளிதில் கணிக்க முடியும் என்பதை செர்ஜி உணர்ந்தார்.

ரயில் நிலையம் வடக்கு உக்ரைன் மற்றும் மேற்கு ரஷ்யாவிலிருந்து அருகிலுள்ள இறைச்சிக் கூடத்திற்குச் செல்லும் ரயில்களில் மாடுகளை வரிசைப்படுத்தும்போது மட்டுமே இடையூறுகள் ஏற்பட்டன என்பதை அவர் விரைவில் அறிந்து கொண்டார். இது விசித்திரமானது, ஏனென்றால் கஜகஸ்தானில் மிக நெருக்கமாக அமைந்துள்ள பண்ணைகளால் இறைச்சிக் கூடம் வழங்கப்பட்டது.

செர்னோபில் அணுமின் நிலையம் 1986 இல் வெடித்தது, மேலும் கதிரியக்க வீழ்ச்சி சுற்றியுள்ள பகுதிகளை மக்கள் வாழத் தகுதியற்றதாக மாற்றியது. வடக்கு உக்ரைன், பெலாரஸ் மற்றும் மேற்கு ரஷ்யாவின் பரந்த பகுதிகள் மாசுபட்டன. வரும் வண்டிகளில் அதிக அளவு கதிர்வீச்சு இருப்பதாக சந்தேகிக்க, செர்ஜி இந்த கோட்பாட்டை சோதிக்க ஒரு முறையை உருவாக்கினார். மக்கள் டோசிமீட்டர்கள் வைத்திருப்பது தடைசெய்யப்பட்டது, எனவே செர்ஜி ரயில் நிலையத்தில் பல இராணுவ வீரர்களுடன் தன்னைப் பதிவுசெய்தார். பல ஓட்கா பானங்களுக்குப் பிறகு, சந்தேகத்திற்கிடமான வண்டிகளில் ஒன்றில் கதிர்வீச்சு அளவை அளவிட ஒரு சிப்பாயை சமாதானப்படுத்த முடிந்தது. சாதாரண மதிப்புகளை விட நிலை பல மடங்கு அதிகமாக இருந்தது என்று மாறியது.

கால்நடைகள் அதிக கதிர்வீச்சை வெளியிடுவது மட்டுமல்லாமல், அதன் நிலை மிகவும் அதிகமாக இருந்தது, இது நிலையத்திற்கு அடுத்த ஒரு கட்டிடத்தில் அமைந்திருந்த SM-1800 இன் நினைவகத்தில் சீரற்ற பிட்களை இழக்க வழிவகுத்தது.

சோவியத் ஒன்றியத்தில் உணவுப் பற்றாக்குறை ஏற்பட்டது, மேலும் செர்னோபில் இறைச்சியை நாட்டின் பிற பகுதிகளிலிருந்து இறைச்சியுடன் கலக்க அதிகாரிகள் முடிவு செய்தனர். மதிப்புமிக்க வளங்களை இழக்காமல் கதிரியக்கத்தின் ஒட்டுமொத்த அளவைக் குறைக்க இது சாத்தியமாக்கியது. இதைப் பற்றி அறிந்த செர்ஜி உடனடியாக குடியேற்றத்திற்கான ஆவணங்களை நிரப்பினார். மேலும் காலப்போக்கில் கதிர்வீச்சு அளவு குறையும்போது கணினி செயலிழப்புகள் தானாக நின்றுவிட்டன.

குழாய்கள் மூலம்

ஒரு காலத்தில், மூவிடெக் சொல்யூஷன்ஸ் சினிமாக்களுக்கான மென்பொருளை உருவாக்கியது, கணக்கியல், டிக்கெட் விற்பனை மற்றும் பொது நிர்வாகத்திற்காக வடிவமைக்கப்பட்டது. ஃபிளாக்ஷிப் பயன்பாட்டின் DOS பதிப்பு வட அமெரிக்காவில் உள்ள சிறிய மற்றும் நடுத்தர அளவிலான திரையரங்குகளில் மிகவும் பிரபலமானது. விண்டோஸ் 95 பதிப்பு அறிவிக்கப்பட்டதும், சமீபத்திய தொடுதிரைகள் மற்றும் சுய-சேவை கியோஸ்க்களுடன் ஒருங்கிணைக்கப்பட்டு, அனைத்து வகையான அறிக்கையிடல் கருவிகளுடன் கூடியதும், அது விரைவில் பிரபலமடைந்ததில் ஆச்சரியமில்லை. பெரும்பாலும் புதுப்பிப்பு எந்த பிரச்சனையும் இல்லாமல் சென்றது. உள்ளூர் தகவல் தொழில்நுட்ப ஊழியர்கள் புதிய உபகரணங்களை நிறுவினர், தரவு இடம்பெயர்ந்தனர் மற்றும் வணிகம் தொடர்ந்தது. அது நீடிக்காதபோது தவிர. இது நடந்தபோது, ​​​​நிறுவனம் "தி கிளீனர்" என்ற புனைப்பெயர் கொண்ட ஜேம்ஸை அனுப்பும்.

புனைப்பெயர் ஒரு மோசமான வகையைக் குறிக்கிறது என்றாலும், கிளீனர் என்பது பயிற்றுவிப்பாளர், நிறுவி மற்றும் ஜாக்-ஆல்-டிரேடுகளின் கலவையாகும். ஜேம்ஸ் வாடிக்கையாளரின் தளத்தில் அனைத்து கூறுகளையும் ஒன்றாகச் சேர்த்து சில நாட்கள் செலவழிப்பார், பின்னர் புதிய அமைப்பை எவ்வாறு பயன்படுத்துவது, வன்பொருள் சிக்கல்கள் ஏற்பட்டால் அவற்றைத் தீர்ப்பது மற்றும் மென்பொருளை அதன் குழந்தைப் பருவத்தில் உதவுவது போன்றவற்றை ஊழியர்களுக்கு கற்பிப்பதில் இன்னும் இரண்டு நாட்கள் செலவிடுவார்.

எனவே, இந்த பரபரப்பான காலங்களில், ஜேம்ஸ் காலையில் அலுவலகத்திற்கு வந்ததில் ஆச்சரியமில்லை, அவர் தனது மேசையை அடைவதற்கு முன்பே, வழக்கத்திற்கு மாறாக காஃபின் நிரப்பப்பட்ட மேலாளரால் அவரை வரவேற்றார்.

"நீங்கள் அன்னாபோலிஸ், நோவா ஸ்கோடியா, சீக்கிரம் செல்ல வேண்டும் என்று நான் பயப்படுகிறேன்." அவர்களின் முழு அமைப்பும் செயலிழந்தது, அவர்களின் பொறியாளர்களுடன் ஒரு இரவு வேலை செய்த பிறகு, என்ன நடந்தது என்பதை எங்களால் கண்டுபிடிக்க முடியவில்லை. சர்வரில் நெட்வொர்க் தோல்வியடைந்தது போல் தெரிகிறது. ஆனால் கணினி பல நிமிடங்கள் இயங்கிய பிறகுதான்.

- அவர்கள் பழைய முறைக்குத் திரும்பவில்லையா? - ஜேம்ஸ் முற்றிலும் தீவிரமாக பதிலளித்தார், இருப்பினும் மனதளவில் அவர் ஆச்சரியத்தில் கண்களை விரித்தார்.

— சரியாக: அவர்களின் IT நிபுணர் “முன்னுரிமைகளை மாற்றி”, அவர்களின் பழைய சேவையகத்துடன் வெளியேற முடிவு செய்தார். ஜேம்ஸ், அவர்கள் ஆறு தளங்களில் கணினியை நிறுவினர் மற்றும் பிரீமியம் ஆதரவுக்காக பணம் செலுத்தினர், மேலும் அவர்களின் வணிகம் இப்போது 1950 களில் இருந்தது போல் இயங்குகிறது.

ஜேம்ஸ் லேசாக நிமிர்ந்தான்.

- அது வேறு விஷயம். சரி, ஆரம்பிக்கலாம்.

அவர் அனாபோலிஸுக்கு வந்ததும், அவர் செய்த முதல் காரியம், பிரச்சனை உள்ள வாடிக்கையாளரின் முதல் தியேட்டரைக் கண்டறிவதுதான். விமான நிலையத்தில் எடுக்கப்பட்ட வரைபடத்தில், எல்லாம் கண்ணியமாகத் தெரிந்தது, ஆனால் விரும்பிய முகவரியைச் சுற்றியுள்ள பகுதி சந்தேகத்திற்குரியதாகத் தோன்றியது. கெட்டோ அல்ல, ஆனால் ஃபிலிம் நோயரை நினைவூட்டுகிறது. ஜேம்ஸ் கர்ப் டவுன்டவுனில் நிறுத்தப்பட்டபோது, ​​ஒரு விபச்சாரி அவரை அணுகினார். அன்னாபோலிஸின் அளவைக் கருத்தில் கொண்டு, இது முழு நகரத்திலும் ஒரே மாதிரியாக இருக்கலாம். அவரது தோற்றம் உடனடியாக பெரிய திரையில் பணத்திற்காக செக்ஸ் வழங்கும் பிரபலமான கதாபாத்திரத்தை நினைவுபடுத்தியது. இல்லை, ஜூலியா ராபர்ட்ஸைப் பற்றி அல்ல, ஆனால் ஜான் வொய்ட்டைப் பற்றி ["மிட்நைட் கவ்பாய்" படத்தின் குறிப்பு - தோராயமாக. பாதை].

விபச்சாரியை வழியனுப்பிவிட்டு, ஜேம்ஸ் சினிமாவுக்குச் சென்றார். சுற்றியுள்ள பகுதி நன்றாக இருந்தது, ஆனால் அது இன்னும் ஓடுவது போன்ற தோற்றத்தை அளித்தது. ஜேம்ஸ் மிகவும் கவலைப்படவில்லை. அவர் முன்பு மோசமான இடங்களுக்குச் சென்றிருக்கிறார். இது கனடாவில் இருந்தது, அங்கு கப்பலில் ஈடுபடுபவர்கள் கூட உங்கள் பணப்பையை எடுத்துக்கொண்ட பிறகு "நன்றி" என்று சொல்லும் அளவுக்கு கண்ணியமாக இருக்கிறார்கள்.

திரையரங்கின் பக்கவாயில் இருண்ட சந்தில் இருந்தது. ஜேம்ஸ் கதவைத் தட்டினான். சிறிது நேரத்தில் அது சத்தமிட்டு லேசாகத் திறந்தது.

- நீங்கள் ஒரு துப்புரவு தொழிலாளியா? - உள்ளிருந்து கரகரப்பான குரல் வந்தது.

- ஆம், நான் தான் ... நான் எல்லாவற்றையும் சரிசெய்ய வந்தேன்.

ஜேம்ஸ் சினிமா லாபிக்குள் நுழைந்தார். வேறு வழியில்லாததால், ஊழியர்கள் பார்வையாளர்களுக்கு காகித டிக்கெட்டுகளை வழங்கத் தொடங்கினர். இது நிதி அறிக்கையை கடினமாக்கியது, மேலும் சுவாரஸ்யமான விவரங்கள் ஒருபுறம் இருக்கட்டும். ஆனால் ஊழியர்கள் ஜேம்ஸை நிம்மதியாக வரவேற்று உடனடியாக சர்வர் அறைக்கு அழைத்துச் சென்றனர்.

முதல் பார்வையில், எல்லாம் நன்றாக இருந்தது. ஜேம்ஸ் சர்வரில் உள்நுழைந்து வழக்கமான சந்தேகத்திற்கிடமான இடங்களைச் சரிபார்த்தார். எந்த பிரச்சினையும் இல்லை. இருப்பினும், மிகுந்த எச்சரிக்கையுடன், ஜேம்ஸ் சர்வரை மூடிவிட்டு, நெட்வொர்க் கார்டை மாற்றி, கணினியை மீண்டும் சுருட்டினார். அவள் உடனடியாக முழுமையாக வேலை செய்ய ஆரம்பித்தாள். ஊழியர்கள் மீண்டும் டிக்கெட் விற்கத் தொடங்கினர்.

ஜேம்ஸ் மார்க்கை அழைத்து நிலைமையைத் தெரிவித்தார். ஜேம்ஸ் சுற்றி ஒட்டிக்கொண்டு ஏதாவது எதிர்பாராதவிதமாக நடந்தால் பார்க்க விரும்புவார் என்று கற்பனை செய்வது கடினம் அல்ல. அவர் படிக்கட்டுகளில் இருந்து இறங்கி ஊழியர்களிடம் என்ன நடந்தது என்று கேட்க ஆரம்பித்தார். வெளிப்படையாக, கணினி வேலை செய்வதை நிறுத்திவிட்டது. அவர்கள் அதை அணைத்துவிட்டு, எல்லாம் வேலை செய்தார்கள். ஆனால் 10 நிமிடங்களுக்குப் பிறகு கணினி செயலிழந்தது.

இந்த நேரத்தில் தான் அப்படி ஒரு சம்பவம் நடந்தது. திடீரென்று, டிக்கெட் முறை பிழைகளை வீசத் தொடங்கியது. ஊழியர்கள் பெருமூச்சு விட்டபடி பேப்பர் டிக்கெட்டுகளை எடுக்க, ஜேம்ஸ் சர்வர் அறைக்கு விரைந்தார். சர்வரில் எல்லாம் நன்றாக இருந்தது.

அப்போது ஊழியர் ஒருவர் உள்ளே நுழைந்தார்.

- அமைப்பு மீண்டும் வேலை செய்கிறது.

அவர் எதுவும் செய்யாததால் ஜேம்ஸ் குழப்பமடைந்தார். இன்னும் துல்லியமாக, கணினியை வேலை செய்யக்கூடிய எதுவும் இல்லை. அவர் வெளியேறி, தனது தொலைபேசியை எடுத்து, தனது நிறுவனத்தின் ஆதரவு லைனுக்கு அழைத்தார். சிறிது நேரத்தில் அதே ஊழியர் சர்வர் அறைக்குள் நுழைந்தார்.

- அமைப்பு செயலிழந்தது.

ஜேம்ஸ் சர்வரைப் பார்த்தார். பல வண்ண வடிவங்களின் சுவாரஸ்யமான மற்றும் பழக்கமான வடிவம் திரையில் நடனமாடியது - குழப்பமான நெளிவு மற்றும் பின்னிப்பிணைந்த குழாய்கள். இந்த ஸ்கிரீன்சேவரை நாம் அனைவரும் ஒரு கட்டத்தில் பார்த்திருக்கிறோம். இது அழகாக வழங்கப்பட்டுள்ளது மற்றும் உண்மையில் ஹிப்னாடிஸாக இருந்தது.

ஜேம்ஸ் ஒரு பொத்தானை அழுத்தினார் மற்றும் முறை மறைந்துவிட்டது. அவர் டிக்கெட் அலுவலகத்திற்கு விரைந்தார், வழியில் அவரிடம் திரும்பி வரும் ஒரு ஊழியரை சந்தித்தார்.

- அமைப்பு மீண்டும் வேலை செய்கிறது.

நீங்கள் ஒரு மன முகபாம் செய்ய முடியும் என்றால், ஜேம்ஸ் சரியாக என்ன செய்தார். ஸ்கிரீன்சேவர். இது OpenGL ஐப் பயன்படுத்துகிறது. எனவே, செயல்பாட்டின் போது, ​​​​இது சேவையக செயலியின் அனைத்து வளங்களையும் பயன்படுத்துகிறது. இதன் விளைவாக, சேவையகத்திற்கான ஒவ்வொரு அழைப்பும் காலக்கெடுவுடன் முடிவடைகிறது.

ஜேம்ஸ் சர்வர் அறைக்குத் திரும்பினார், உள்நுழைந்து, ஸ்கிரீன்சேவரை வெற்றுத் திரையுடன் அழகான குழாய்களுடன் மாற்றினார். அதாவது, 100% செயலி வளங்களைப் பயன்படுத்தும் ஸ்கிரீன்சேவருக்குப் பதிலாக, வளங்களைப் பயன்படுத்தாத இன்னொன்றை நிறுவினேன். பிறகு 10 நிமிடங்கள் காத்திருந்து என் யூகத்தைச் சரிபார்த்தேன்.

ஜேம்ஸ் அடுத்த திரையரங்கிற்கு வந்ததும், ஸ்க்ரீன் சேவரை அணைக்க தான் 800 கி.மீ பறந்து வந்ததை தன் மேனேஜரிடம் எப்படி விளக்குவது என்று யோசித்துக் கொண்டிருந்தான்.

நிலவின் ஒரு குறிப்பிட்ட கட்டத்தில் விபத்து

உண்மைக்கதை. ஒரு நாள் சந்திரனின் கட்டத்தைப் பொறுத்து ஒரு மென்பொருள் பிழை எழுந்தது. சந்திரனின் உண்மையான கட்டத்தின் தோராயத்தைக் கணக்கிடுவதற்கு பல்வேறு MIT திட்டங்களில் பொதுவாகப் பயன்படுத்தப்படும் ஒரு சிறிய வழக்கம் இருந்தது. GLS இந்த வழக்கத்தை ஒரு LISP நிரலாக உருவாக்கியது, இது ஒரு கோப்பை எழுதும் போது, ​​கிட்டத்தட்ட 80 எழுத்துகள் நீளமுள்ள நேர முத்திரையுடன் ஒரு வரியை வெளியிடும். ஒரு செய்தியின் முதல் வரி மிக நீண்டதாக முடிந்து அடுத்த வரிக்கு இட்டுச் செல்வது மிகவும் அரிது. நிரல் பின்னர் இந்த கோப்பைப் படித்தபோது, ​​​​அது சபித்தது. முதல் வரியின் நீளம் சரியான தேதி மற்றும் நேரத்தைச் சார்ந்தது, அத்துடன் நேர முத்திரை அச்சிடப்பட்ட நேரத்தின் கட்ட விவரக்குறிப்பின் நீளத்தைப் பொறுத்தது. அதாவது, பிழை உண்மையில் சந்திரனின் கட்டத்தைப் பொறுத்தது!

முதல் தாள் பதிப்பு வாசக கோப்பு (Steele-1983) விவரிக்கப்பட்ட பிழைக்கு வழிவகுத்த அத்தகைய வரியின் உதாரணம் உள்ளது, ஆனால் தட்டச்சுப்பொறி அதை "சரி" செய்தது. இது "மூன் பேஸ் பிழை" என்று விவரிக்கப்பட்டது.

இருப்பினும், அனுமானங்களில் கவனமாக இருங்கள். சில ஆண்டுகளுக்கு முன்பு, CERN (ஐரோப்பிய அணு ஆராய்ச்சி மையம்) இன் பொறியாளர்கள் பெரிய எலக்ட்ரான்-பாசிட்ரான் மோதலில் மேற்கொள்ளப்பட்ட சோதனைகளில் பிழைகளை எதிர்கொண்டனர். விஞ்ஞானிகளுக்கு முடிவைக் காண்பிப்பதற்கு முன், இந்தச் சாதனத்தால் உருவாக்கப்பட்ட அபரிமிதமான தரவை கணினிகள் தீவிரமாகச் செயலாக்குவதால், இந்த மென்பொருள் சந்திரனின் கட்டத்திற்கு எப்படியோ உணர்திறன் கொண்டது என்று பலர் ஊகித்தனர். பல அவநம்பிக்கையான பொறியாளர்கள் உண்மையின் அடிப்பகுதிக்கு வந்தனர். சந்திரன் கடந்து செல்லும் போது பூமியின் உருமாற்றத்தால் 27 கிமீ நீளமுள்ள வளையத்தின் வடிவவியலில் சிறிது மாற்றம் ஏற்பட்டதால் பிழை ஏற்பட்டது! இந்தக் கதை இயற்பியல் நாட்டுப்புறக் கதைகளில் "நியூட்டனின் துகள் இயற்பியலின் பழிவாங்கல்" மற்றும் இயற்பியலின் எளிய மற்றும் பழமையான விதிகள் மற்றும் மிகவும் மேம்பட்ட அறிவியல் கருத்துக்களுக்கு இடையிலான தொடர்பின் ஒரு எடுத்துக்காட்டு.

கழிப்பறையை கழுவினால் ரயில் நிற்கிறது

நான் கேள்விப்பட்டதில் சிறந்த வன்பொருள் பிழை பிரான்சில் அதிவேக ரயிலில் இருந்தது. பிழையானது ரயிலின் அவசர பிரேக்கிங்கிற்கு வழிவகுத்தது, ஆனால் அதில் பயணிகள் இருந்தால் மட்டுமே. இதுபோன்ற ஒவ்வொரு சந்தர்ப்பத்திலும், ரயில் சேவையில் இருந்து அகற்றப்பட்டது, சோதனை செய்யப்பட்டது, ஆனால் எதுவும் கிடைக்கவில்லை. பின்னர் அவர் மீண்டும் வரிக்கு அனுப்பப்பட்டார், அவர் உடனடியாக ஒரு நிறுத்தத்தில் மோதினார்.

சோதனை ஒன்றின் போது, ​​ரயிலில் பயணம் செய்த பொறியாளர் ஒருவர் கழிவறைக்குச் சென்றார். அவர் விரைவில் கழுவி, பூம்! அவசர நிறுத்தம்.

பொறியாளர் டிரைவரை தொடர்பு கொண்டு கேட்டார்:

- பிரேக் போடுவதற்கு முன்பு நீங்கள் என்ன செய்து கொண்டிருந்தீர்கள்?

- சரி, நான் இறங்குவதை மெதுவாக்கினேன் ...

இது விசித்திரமானது, ஏனென்றால் சாதாரண செயல்பாட்டின் போது ரயில் டஜன் கணக்கான முறை இறக்கத்தில் மெதுவாக செல்கிறது. ரயில் நகர்ந்தது, அடுத்த இறக்கத்தில் டிரைவர் எச்சரித்தார்:

- நான் மெதுவாகப் போகிறேன்.

எதுவும் நடக்கவில்லை.

- கடைசி பிரேக்கிங்கின் போது நீங்கள் என்ன செய்தீர்கள்? - டிரைவர் கேட்டார்.

- சரி... நான் கழிப்பறையில் இருந்தேன்.

- சரி, கழிப்பறைக்குச் சென்று நாங்கள் மீண்டும் கீழே இறங்கும்போது நீங்கள் செய்ததைச் செய்யுங்கள்!

பொறியாளர் கழிப்பறைக்குச் சென்றார், ஓட்டுநர் எச்சரித்தபோது: "நான் மெதுவாகச் செல்கிறேன்," அவர் தண்ணீரை சுத்தப்படுத்தினார். நிச்சயமாக, ரயில் உடனடியாக நிறுத்தப்பட்டது.

இப்போது அவர்கள் சிக்கலை மீண்டும் உருவாக்க முடியும் மற்றும் காரணத்தைக் கண்டுபிடிக்க வேண்டும்.

இரண்டு நிமிடங்களுக்குப் பிறகு, என்ஜின் பிரேக் ரிமோட் கண்ட்ரோல் கேபிள் (ரயிலின் ஒவ்வொரு முனையிலும் ஒரு இயந்திரம் இருந்தது) மின் பெட்டியின் சுவரில் இருந்து துண்டிக்கப்பட்டு, கழிப்பறை பிளக் சோலனாய்டைக் கட்டுப்படுத்தும் ரிலேயில் கிடந்ததை அவர்கள் கவனித்தனர்... ரிலே இயக்கப்பட்டது, இது பிரேக் கேபிளில் குறுக்கீட்டை உருவாக்கியது, மேலும் தோல்விகளுக்கு எதிரான கணினி பாதுகாப்பு அவசரகால பிரேக்கிங்கை உள்ளடக்கியது.

ஃபோர்ட்ரானை வெறுத்த நுழைவாயில்

சில மாதங்களுக்கு முன்பு, நிலப்பரப்பில் [இது ஹவாயில்] நெட்வொர்க் இணைப்புகள் மிக மிக மெதுவாக வருவதை நாங்கள் கவனித்தோம். இது 10-15 நிமிடங்கள் நீடிக்கும் மற்றும் திடீரென்று மீண்டும் நிகழலாம். சிறிது நேரம் கழித்து, நிலப்பரப்பில் நெட்வொர்க் இணைப்புகள் இருப்பதாக என் சக ஊழியர் என்னிடம் புகார் செய்தார் பொதுவாக வேலை செய்ய வில்லை. நிலப்பரப்பில் உள்ள ஒரு இயந்திரத்திற்கு நகலெடுக்க வேண்டிய சில FORTRAN குறியீடு அவரிடம் இருந்தது, ஆனால் "FTP பதிவேற்றம் முடிவடைவதற்கு நெட்வொர்க் நீண்ட நேரம் வைத்திருக்காததால்" அது முடியவில்லை.

ஆம், சக ஊழியர் ஒருவர் FORTRAN இல் உள்ள மூலக் குறியீட்டைக் கொண்ட ஒரு கோப்பை நிலப்பரப்பில் உள்ள ஒரு இயந்திரத்திற்கு FTP செய்ய முயன்றபோது நெட்வொர்க் தோல்விகள் ஏற்பட்டன. நாங்கள் கோப்பை காப்பகப்படுத்த முயற்சித்தோம்: பின்னர் அது சுமூகமாக நகலெடுக்கப்பட்டது (ஆனால் இலக்கு இயந்திரத்தில் அன்பேக்கர் இல்லை, எனவே சிக்கல் தீர்க்கப்படவில்லை). இறுதியாக FORTRAN குறியீட்டை மிகச் சிறிய துண்டுகளாகப் பிரித்து ஒவ்வொன்றாக அனுப்பினோம். பெரும்பாலான துண்டுகள் சிக்கல்கள் இல்லாமல் நகலெடுக்கப்பட்டன, ஆனால் சில துண்டுகள் கடந்து செல்லவில்லை அல்லது கடந்து செல்லவில்லை ஏராளமான முயற்சிகள்.

சிக்கலான பத்திகளை நாங்கள் ஆய்வு செய்தபோது, ​​அவற்றில் பொதுவான ஒன்று இருப்பதைக் கண்டறிந்தோம்: அவை அனைத்தும் C (FORTRAN இல் கருத்துத் தெரிவிக்க விரும்புவது போல) மூலதனம் கொண்ட வரிகளுடன் தொடங்கி முடிவடையும் கருத்துத் தொகுதிகளைக் கொண்டிருந்தன. நிலப்பரப்பில் உள்ள நெட்வொர்க் நிபுணர்களுக்கு மின்னஞ்சல் அனுப்பி உதவி கேட்டோம். நிச்சயமாக, அவர்கள் FTP வழியாக மாற்ற முடியாத எங்கள் கோப்புகளின் மாதிரிகளைப் பார்க்க விரும்பினர்... ஆனால் எங்கள் கடிதங்கள் அவர்களைச் சென்றடையவில்லை. இறுதியாக நாங்கள் ஒரு எளிய விஷயத்தைக் கொண்டு வந்தோம் விவரிக்கமாற்ற முடியாத கோப்புகள் எப்படி இருக்கும். அது வேலை செய்தது :) [பிரச்சினையான ஃபோர்ட்ரான் கருத்துக்களில் ஒன்றின் உதாரணத்தை இங்கே சேர்க்க தைரியமா? ஒருவேளை அது மதிப்புக்குரியது அல்ல!]

இறுதியில் நாங்கள் அதை கண்டுபிடிக்க முடிந்தது. எங்கள் வளாகத்தின் பகுதிக்கும் பிரதான நிலப்பரப்பு நெட்வொர்க்கிற்கும் இடையே சமீபத்தில் ஒரு புதிய நுழைவாயில் நிறுவப்பட்டது. பெரிய எழுத்து C இன் மீண்டும் மீண்டும் பிட்களைக் கொண்ட பாக்கெட்டுகளை அனுப்புவதில் பெரும் சிரமம் இருந்தது! இந்த பாக்கெட்டுகளில் சில அனைத்து நுழைவாயில் ஆதாரங்களையும் எடுத்துக் கொள்ளலாம் மற்றும் பிற பாக்கெட்டுகளைப் பெறுவதைத் தடுக்கலாம். கேட்வே உற்பத்தியாளரிடம் நாங்கள் புகார் செய்தோம்... அவர்கள் பதிலளித்தனர்: "ஓ, ஆம், நீங்கள் மீண்டும் மீண்டும் C இன் பிழையை எதிர்கொள்கிறீர்கள்! அவரைப் பற்றி எங்களுக்கு ஏற்கனவே தெரியும். மற்றொரு உற்பத்தியாளரிடமிருந்து புதிய நுழைவாயிலை வாங்குவதன் மூலம் நாங்கள் சிக்கலைத் தீர்த்தோம் (முன்னாள் பாதுகாப்பில், FORTRAN திட்டங்களை மாற்ற இயலாமை சிலருக்கு ஒரு நன்மையாக இருக்கலாம்!).

கடினமான நேரங்கள்

சில ஆண்டுகளுக்கு முன்பு, கட்டம் 40 மருத்துவ பரிசோதனைகளின் செலவைக் குறைக்க பெர்லில் ETL அமைப்பை உருவாக்கும் பணியில் ஈடுபட்டிருந்தபோது, ​​நான் சுமார் 000 தேதிகளைச் செயல்படுத்த வேண்டியிருந்தது. அவர்களில் இருவர் தேர்வில் தேர்ச்சி பெறவில்லை. இது என்னை அதிகம் தொந்தரவு செய்யவில்லை, ஏனெனில் இந்த தேதிகள் கிளையன்ட் வழங்கிய தரவுகளிலிருந்து எடுக்கப்பட்டவை, இது பெரும்பாலும் ஆச்சரியமாக இருந்தது. ஆனால் அசல் தரவை நான் சரிபார்த்தபோது, ​​இந்த தேதிகள் ஜனவரி 1, 2011 மற்றும் ஜனவரி 1, 2007 என்று மாறியது. நான் எழுதிய நிரலில் பிழை உள்ளது என்று நினைத்தேன், ஆனால் அது ஏற்கனவே 30 ஆண்டுகள் ஆனது. பழைய. மென்பொருள் சுற்றுச்சூழலைப் பற்றி அறிமுகமில்லாதவர்களுக்கு இது மர்மமாகத் தோன்றலாம். பணம் சம்பாதிப்பதற்கான மற்றொரு நிறுவனத்தின் நீண்டகால முடிவின் காரணமாக, ஒரு நிறுவனம் தற்செயலாகவும் மற்றொன்று வேண்டுமென்றே அறிமுகப்படுத்திய பிழையை சரிசெய்ய எனது வாடிக்கையாளர் எனக்கு பணம் கொடுத்தார். நான் எதைப் பற்றி பேசுகிறேன் என்பதைப் புரிந்துகொள்வதற்கு, பிழையாக மாறிய அம்சத்தைச் சேர்த்த நிறுவனத்தைப் பற்றியும், நான் சரிசெய்த மர்மமான பிழைக்கு பங்களித்த வேறு சில சுவாரஸ்யமான நிகழ்வுகளைப் பற்றியும் பேச வேண்டும்.

நல்ல பழைய நாட்களில், ஆப்பிள் கணினிகள் சில நேரங்களில் தன்னிச்சையாக ஜனவரி 1, 1904 க்கு தங்கள் தேதியை மீட்டமைக்கும். காரணம் எளிமையானது: தேதி மற்றும் நேரத்தைக் கண்காணிக்க பேட்டரியில் இயங்கும் "கணினி கடிகாரம்" பயன்படுத்தப்பட்டது. பேட்டரி இறந்தபோது என்ன நடந்தது? ஒரு சகாப்தத்தின் தொடக்கத்திலிருந்து கணினிகள் தேதியை வினாடிகளின் எண்ணிக்கையால் கண்காணிக்கத் தொடங்கின. சகாப்தத்தின் மூலம் நாங்கள் குறிப்பு அசல் தேதியைக் குறிக்கிறோம், மேகிண்டோஷுக்கு அது ஜனவரி 1, 1904. மேலும் பேட்டரி இறந்த பிறகு, தற்போதைய தேதி குறிப்பிட்ட தேதிக்கு மீட்டமைக்கப்பட்டது. ஆனால் இது ஏன் நடந்தது?

முன்னதாக, அசல் தேதியிலிருந்து வினாடிகளின் எண்ணிக்கையை சேமிக்க ஆப்பிள் 32 பிட்களைப் பயன்படுத்தியது. ஒரு பிட் இரண்டு மதிப்புகளில் ஒன்றைச் சேமிக்கலாம் - 1 அல்லது 0. இரண்டு பிட்கள் நான்கு மதிப்புகளில் ஒன்றைச் சேமிக்கலாம்: 00, 01, 10, 11. மூன்று பிட்கள் - எட்டில் ஒரு மதிப்பு: 000, 001, 010, 011, 100 , 101, 110, 111, முதலியன மேலும் 32 ஆனது 232 மதிப்புகளில் ஒன்றை சேமிக்க முடியும், அதாவது 4 வினாடிகள். ஆப்பிள் தேதிகளைப் பொறுத்தவரை, இது சுமார் 294 ஆண்டுகளுக்கு சமம், எனவே பழைய மேக்ஸால் 967 க்குப் பிறகு தேதிகளைக் கையாள முடியாது. மேலும் கணினி பேட்டரி இறந்துவிட்டால், சகாப்தத்தின் தொடக்கத்திலிருந்து தேதி 296 வினாடிகளுக்கு மீட்டமைக்கப்படும், மேலும் ஒவ்வொரு முறையும் நீங்கள் கணினியை இயக்கும்போது (அல்லது புதிய பேட்டரியை வாங்கும் வரை) தேதியை கைமுறையாக அமைக்க வேண்டும்.

எவ்வாறாயினும், சகாப்தத்திலிருந்து தேதிகளை வினாடிகளாக சேமிக்க ஆப்பிள் எடுத்த முடிவு, சகாப்தத்திற்கு முந்தைய தேதிகளை எங்களால் கையாள முடியவில்லை, இது தொலைநோக்கு விளைவுகளை ஏற்படுத்தியது, நாம் பார்ப்போம். ஆப்பிள் ஒரு அம்சத்தை அறிமுகப்படுத்தியது, ஒரு பிழை அல்ல. மற்றவற்றுடன், மேகிண்டோஷ் இயக்க முறைமையானது "மில்லினியம் பிழை" (கட்டுப்பாடுகளைத் தவிர்ப்பதற்கு அவற்றின் சொந்த தேதி அமைப்புகளைக் கொண்ட பல மேக் பயன்பாடுகளைப் பற்றி கூற முடியாது) நோய் எதிர்ப்பு சக்தி கொண்டது என்பதை இது குறிக்கிறது.

மேலே போ. நாங்கள் Lotus 1-2-3 ஐப் பயன்படுத்தினோம், IBM இன் "கில்லர் அப்ளிகேஷன்" இது PC புரட்சியைத் தொடங்க உதவியது, இருப்பினும் Apple கணினிகளில் VisiCalc இருந்தது, இது தனிப்பட்ட கணினியை வெற்றியடையச் செய்தது. நியாயமாக, 1-2-3 தோன்றவில்லை என்றால், பிசிக்கள் அரிதாகவே புறப்பட்டிருக்காது, மேலும் தனிப்பட்ட கணினிகளின் வரலாறு மிகவும் வித்தியாசமாக வளர்ந்திருக்கும். தாமரை 1-2-3 1900 ஐ லீப் ஆண்டாக தவறாகக் கருதியது. மைக்ரோசாப்ட் அதன் முதல் விரிதாளான மல்டிபிளானை வெளியிட்டபோது, ​​அது சந்தையில் ஒரு சிறிய பங்கைக் கைப்பற்றியது. அவர்கள் எக்செல் திட்டத்தைத் தொடங்கியபோது, ​​தாமரை 1-2-3 இலிருந்து வரிசை மற்றும் நெடுவரிசை பெயரிடும் திட்டத்தை நகலெடுப்பது மட்டுமல்லாமல், 1900 ஐ லீப் ஆண்டாக வேண்டுமென்றே கருதுவதன் மூலம் பிழை இணக்கத்தன்மையை உறுதிப்படுத்தவும் முடிவு செய்தனர். இந்த பிரச்சனை இன்றும் உள்ளது. அதாவது, 1-2-3 இல் இது ஒரு பிழை, ஆனால் எக்செல் இல் இது ஒரு நனவான முடிவாகும், இது அனைத்து 1-2-3 பயனர்களும் தங்கள் அட்டவணையை எக்செல் இல் தரவை மாற்றாமல், அது தவறாக இருந்தாலும் இறக்குமதி செய்யலாம் என்பதை உறுதி செய்தது.

ஆனால் இன்னொரு பிரச்சனையும் இருந்தது. முதலில், மைக்ரோசாப்ட் மேகிண்டோஷிற்காக எக்செல் வெளியிட்டது, இது ஜனவரி 1, 1904க்கு முந்தைய தேதிகளை அங்கீகரிக்கவில்லை. மேலும் எக்செல் இல், ஜனவரி 1, 1900 சகாப்தத்தின் தொடக்கமாகக் கருதப்பட்டது. எனவே, டெவலப்பர்கள் ஒரு மாற்றத்தை உருவாக்கினர், இதனால் அவர்களின் நிரல் சகாப்தத்தின் வகையை அங்கீகரித்து, விரும்பிய சகாப்தத்திற்கு ஏற்ப தரவை தனக்குள்ளேயே சேமிக்கிறது. மைக்ரோசாப்ட் இதைப் பற்றி ஒரு விளக்கக் கட்டுரையை கூட எழுதியது. இந்த முடிவு எனது பிழைக்கு வழிவகுத்தது.

எனது ETL அமைப்பு, Windows இல் உருவாக்கப்பட்ட வாடிக்கையாளர்களிடமிருந்து Excel விரிதாள்களைப் பெற்றது, ஆனால் Macல் உருவாக்கப்படலாம். எனவே, அட்டவணையில் சகாப்தத்தின் ஆரம்பம் ஜனவரி 1, 1900 அல்லது ஜனவரி 1, 1904 ஆக இருக்கலாம். எப்படி கண்டுபிடிப்பது? எக்செல் கோப்பு வடிவம் தேவையான தகவலைக் காட்டுகிறது, ஆனால் நான் பயன்படுத்திய பாகுபடுத்தி அதைக் காட்டவில்லை (இப்போது அது செய்கிறது), மேலும் ஒரு குறிப்பிட்ட அட்டவணையின் சகாப்தம் உங்களுக்குத் தெரியும் என்று கருதுகிறது. எக்செல் பைனரி வடிவமைப்பைப் புரிந்துகொள்வதற்கும், பாகுபடுத்தி ஆசிரியருக்கு ஒரு பேட்ச் அனுப்புவதற்கும் நான் அதிக நேரம் செலவழித்திருக்கலாம், ஆனால் கிளையண்டிற்காக நான் இன்னும் நிறைய செய்ய வேண்டியிருந்தது, எனவே சகாப்தத்தை தீர்மானிக்க விரைவாக ஒரு ஹூரிஸ்டிக் எழுதினேன். அவள் எளிமையாக இருந்தாள்.

Excel இல், ஜூலை 5, 1998 தேதியை "07-05-98" (பயனற்ற அமெரிக்க அமைப்பு), "Jul 5, 98", "July 5, 1998", "5-Jul-98" அல்லது வேறு சில வடிவம். மற்றொரு பயனற்ற வடிவம் (முரண்பாடாக, எக்செல் எனது பதிப்பு வழங்காத வடிவங்களில் ஒன்று ISO 8601 ஆகும்). இருப்பினும், அட்டவணையில், வடிவமைக்கப்படாத தேதியானது சகாப்தம்-35981 க்கு "1900" அல்லது சகாப்தம்-34519 க்கான "1904" ஆக சேமிக்கப்பட்டது (எண்கள் சகாப்தத்திலிருந்து நாட்களின் எண்ணிக்கையைக் குறிக்கின்றன). வடிவமைக்கப்பட்ட தேதியிலிருந்து ஆண்டைப் பிரித்தெடுக்க நான் ஒரு எளிய பாகுபடுத்தியைப் பயன்படுத்தினேன், பின்னர் வடிவமைக்கப்படாத தேதியிலிருந்து ஆண்டைப் பிரித்தெடுக்க எக்செல் பாகுபடுத்தியைப் பயன்படுத்தினேன். இரண்டு மதிப்புகளும் 4 ஆண்டுகள் வித்தியாசமாக இருந்தால், நான் சகாப்தம்-1904 உடன் ஒரு அமைப்பைப் பயன்படுத்துகிறேன் என்று எனக்குத் தெரியும்.

நான் ஏன் வடிவமைக்கப்பட்ட தேதிகளைப் பயன்படுத்தவில்லை? ஏனெனில், 5 ஆம் ஆண்டு ஜூலை 1998 ஆம் தேதியை "ஜூலை, 98" என வடிவமைத்து, அந்த மாதத்தின் நாள் இழந்ததைக் கொண்டு வடிவமைக்க முடியும். பல நிறுவனங்களிடமிருந்து நாங்கள் அட்டவணைகளைப் பெற்றோம், அவை பல வழிகளில் அவற்றை உருவாக்கின, தேதிகளைக் கண்டுபிடிப்பது எங்களுடையது (இந்த விஷயத்தில், நான்). தவிர, எக்செல் அதை சரியாகப் பெற்றால், நாமும் அவ்வாறு செய்ய வேண்டும்!

அதே நேரத்தில் நான் 39082 ஐ சந்தித்தேன். தாமரை 1-2-3 1900 ஐ ஒரு லீப் ஆண்டாகக் கருதியது என்பதை உங்களுக்கு நினைவூட்டுகிறேன், மேலும் இது எக்செல் இல் உண்மையாக மீண்டும் மீண்டும் செய்யப்பட்டது. இது 1900 ஆம் ஆண்டுடன் ஒரு நாளைச் சேர்த்ததால், பல தேதி கணக்கீடு செயல்பாடுகள் அந்த நாளிலேயே தவறாக இருக்கலாம். அதாவது, 39082 என்பது ஜனவரி 1, 2011 (மேக்ஸில்) அல்லது டிசம்பர் 31, 2006 (விண்டோஸில்) ஆக இருக்கலாம். எனது "ஆண்டு பாகுபடுத்தி" 2011 ஆம் ஆண்டை வடிவமைக்கப்பட்ட மதிப்பிலிருந்து பிரித்தெடுத்தால், எல்லாம் சரியாக இருக்கும். ஆனால் எக்செல் பாகுபடுத்தி என்ன சகாப்தம் பயன்படுத்தப்படுகிறது என்று தெரியாததால், அது எபோக்-1900 க்கு இயல்புநிலையாகி, 2006 ஆம் ஆண்டிற்கு திரும்பும். எனது விண்ணப்பம் 5 ஆண்டுகள் வித்தியாசம் இருப்பதைக் கண்டது, அதை பிழையாகக் கருதி, பதிவுசெய்து, வடிவமைக்கப்படாத மதிப்பை வழங்கியது.

இதைப் போக்க, நான் இதை எழுதினேன் (சூடோகோட்):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

பின்னர் அனைத்து 40 தேதிகளும் சரியாக பாகுபடுத்தப்பட்டன.

பெரிய அச்சு வேலைகளுக்கு நடுவில்

1980 களின் முற்பகுதியில், எனது தந்தை ஸ்டோரேஜ் டெக்னாலஜியில் பணிபுரிந்தார், இது தற்போது செயலிழந்த ஒரு பிரிவான டேப் டிரைவ்கள் மற்றும் அதிவேக டேப் ஃபீடிங்கிற்கான நியூமேடிக் அமைப்புகளை உருவாக்கியது.

ஏழு "பி" டிரைவ்களுடன் இணைக்கப்பட்ட ஒரு மைய "ஏ" டிரைவைக் கொண்டிருக்கும் வகையில் டிரைவ்களை மறுவடிவமைத்தனர், மேலும் "ஏ" டிரைவைக் கட்டுப்படுத்தும் ரேமில் உள்ள சிறிய ஓஎஸ் அனைத்து "பி" டிரைவ்களுக்கும் படிக்க மற்றும் எழுதும் செயல்பாடுகளை வழங்க முடியும்.

ஒவ்வொரு முறை இயக்கி "A" தொடங்கப்பட்டதும், இயக்க முறைமையை அதன் நினைவகத்தில் ஏற்றுவதற்கு "A" உடன் இணைக்கப்பட்ட புற இயக்ககத்தில் ஒரு நெகிழ் வட்டு செருகுவது அவசியம். இது மிகவும் பழமையானது: கணினி ஆற்றல் 8-பிட் மைக்ரோகண்ட்ரோலரால் வழங்கப்பட்டது.

அத்தகைய உபகரணங்களுக்கான இலக்கு பார்வையாளர்கள் மிகப் பெரிய தரவுக் கிடங்குகளைக் கொண்ட நிறுவனங்களாகும் - வங்கிகள், சில்லறை சங்கிலிகள், முதலியன - நிறைய முகவரி லேபிள்கள் அல்லது வங்கி அறிக்கைகளை அச்சிட வேண்டும்.

ஒரு வாடிக்கையாளர் ஒரு பிரச்சனை. அச்சு வேலையின் நடுவில், ஒரு குறிப்பிட்ட இயக்கி "A" வேலை செய்வதை நிறுத்தலாம், இதனால் முழு வேலையும் ஸ்தம்பித்துவிடும். இயக்ககத்தின் செயல்பாட்டை மீட்டெடுக்க, ஊழியர்கள் எல்லாவற்றையும் மறுதொடக்கம் செய்ய வேண்டியிருந்தது. இது ஆறு மணி நேர பணியின் நடுவில் நடந்தால், ஒரு பெரிய அளவு விலையுயர்ந்த கணினி நேரம் இழக்கப்பட்டு முழு செயல்பாட்டின் அட்டவணையும் சீர்குலைந்தது.

ஸ்டோரேஜ் டெக்னாலஜிஸிலிருந்து தொழில்நுட்ப வல்லுநர்கள் அனுப்பப்பட்டனர். ஆனால் அவர்களின் சிறந்த முயற்சிகள் இருந்தபோதிலும், சோதனை நிலைமைகளின் கீழ் அவர்களால் பிழையை மீண்டும் உருவாக்க முடியவில்லை: இது பெரிய அச்சு வேலைகளுக்கு நடுவில் நிகழ்ந்ததாகத் தோன்றியது. பிரச்சனை வன்பொருள் அல்ல, அவர்கள் தங்களால் முடிந்த அனைத்தையும் மாற்றினர்: ரேம், மைக்ரோகண்ட்ரோலர், ஃப்ளாப்பி டிரைவ், டேப் டிரைவின் ஒவ்வொரு சிந்திக்கக்கூடிய பகுதியும் - சிக்கல் நீடித்தது.

பின்னர் தொழில்நுட்ப வல்லுநர்கள் தலைமையகத்தை அழைத்து நிபுணரை அழைத்தனர்.

நிபுணர் ஒரு நாற்காலியையும் ஒரு கப் காபியையும் எடுத்துக் கொண்டு, கணினி அறையில் அமர்ந்தார்-அந்த நாட்களில் கணினிகளுக்கு அர்ப்பணிக்கப்பட்ட அறைகள் இருந்தன- மற்றும் ஊழியர்கள் ஒரு பெரிய அச்சுப் பணியை வரிசையில் நிறுத்துவதைப் பார்த்தார். ஒரு தோல்வி நிகழும் என்று நிபுணர் காத்திருந்தார் - அது நடந்தது. எல்லோரும் நிபுணரைப் பார்த்தார்கள், ஆனால் இது ஏன் நடந்தது என்று அவருக்குத் தெரியவில்லை. எனவே அவர் வேலையை மீண்டும் வரிசையில் வைக்க உத்தரவிட்டார், மேலும் ஊழியர்கள் மற்றும் தொழில்நுட்ப வல்லுநர்கள் அனைவரும் பணிக்குத் திரும்பினர்.

நிபுணர் மீண்டும் நாற்காலியில் அமர்ந்து தோல்விக்காக காத்திருக்கத் தொடங்கினார். சுமார் ஆறு மணி நேரம் கடந்துவிட்டது, தோல்வி ஏற்பட்டது. நிபுணருக்கு மீண்டும் எந்த யோசனையும் இல்லை, எல்லாமே மக்கள் நிறைந்த ஒரு அறையில் நடந்தது என்பதைத் தவிர. பணியை மீண்டும் தொடங்க உத்தரவிட்டு, மீண்டும் அமர்ந்து காத்திருந்தார்.

மூன்றாவது தோல்வியால், நிபுணர் ஒன்றைக் கவனித்தார். ஒரு வெளிநாட்டு டிரைவில் பணியாளர்கள் டேப்களை மாற்றியபோது தோல்வி ஏற்பட்டது. மேலும், ஊழியர்களில் ஒருவர் தரையில் ஒரு குறிப்பிட்ட ஓடு வழியாக நடந்து சென்றவுடன் தோல்வி ஏற்பட்டது.

6 முதல் 8 அங்குல உயரத்தில் போடப்பட்ட அலுமினிய ஓடுகளால் எழுப்பப்பட்ட தளம். ஒரு முக்கியமான கேபிளை யாரும் தற்செயலாக மிதிப்பதைத் தடுக்க, கம்ப்யூட்டர்களில் இருந்து ஏராளமான கம்பிகள் உயர்த்தப்பட்ட தளத்தின் கீழ் ஓடியது. உயரமான தரையின் கீழ் குப்பைகள் சேராமல் இருக்க ஓடுகள் மிகவும் இறுக்கமாக அமைக்கப்பட்டன.

ஓடுகளில் ஒன்று சிதைந்திருப்பதை நிபுணர் உணர்ந்தார். ஒரு ஊழியர் அதன் மூலையில் காலடி எடுத்து வைத்தபோது, ​​ஓடுகளின் விளிம்புகள் அடுத்தடுத்த ஓடுகளில் உராய்ந்தன. ஓடுகளை இணைக்கும் பிளாஸ்டிக் பாகங்களும் அவற்றுடன் தேய்க்கப்பட்டன, இது ரேடியோ அலைவரிசை குறுக்கீட்டை உருவாக்கும் நிலையான மைக்ரோ டிஸ்சார்ஜ்களை ஏற்படுத்தியது.

இன்று, ரேடியோ அலைவரிசை குறுக்கீட்டில் இருந்து ரேம் சிறப்பாக பாதுகாக்கப்படுகிறது. ஆனால் அந்த ஆண்டுகளில் அப்படி இல்லை. இந்த குறுக்கீடு நினைவகத்தை சீர்குலைத்து, அதனுடன் இயக்க முறைமையின் செயல்பாட்டையும் நிபுணர் உணர்ந்தார். அவர் ஆதரவு சேவையை அழைத்தார், புதிய ஓடுகளை ஆர்டர் செய்தார், அவற்றை தானே நிறுவினார், சிக்கல் மறைந்தது.

இது அதிக அலை!

கதை போர்ட்ஸ்மவுத்தில் (நான் நினைக்கிறேன்), கப்பல்துறை பகுதியில் உள்ள ஒரு அலுவலகத்தின் நான்காவது அல்லது ஐந்தாவது மாடியில் உள்ள சர்வர் அறையில் நடந்தது.

ஒரு நாள் பிரதான தரவுத்தளத்துடன் கூடிய யுனிக்ஸ் சர்வர் செயலிழந்தது. அவர்கள் அவரை மீண்டும் துவக்கினர், ஆனால் அவர் மகிழ்ச்சியுடன் மீண்டும் மீண்டும் விழுந்தார். ஆதரவு சேவையிலிருந்து ஒருவரை அழைக்க முடிவு செய்தோம்.

சப்போர்ட் பையன்... அவன் பெயர் மார்க் என்று நினைக்கிறேன், ஆனால் அது முக்கியமில்லை... எனக்கு அவனைத் தெரியாது என்று நினைக்கிறேன். அது முக்கியமில்லை, உண்மையில். மார்க் உடன் ஒட்டிக்கொள்வோம், சரியா? நன்று.

எனவே, சில மணிநேரங்களுக்குப் பிறகு மார்க் வந்தார் (இது லீட்ஸிலிருந்து போர்ட்ஸ்மவுத் வரை நீண்ட தூரம் இல்லை, உங்களுக்குத் தெரியும்), சேவையகத்தை இயக்கியது மற்றும் எல்லாமே சிக்கல்கள் இல்லாமல் வேலை செய்தன. வழக்கமான ஆதரவு, வாடிக்கையாளர் இதைப் பற்றி மிகவும் வருத்தப்படுகிறார். மார்க் பதிவுக் கோப்புகளைப் பார்க்கிறார், மேலும் விரும்பத்தகாத எதையும் காணவில்லை. எனவே மார்க் மீண்டும் ரயிலில் ஏறினார் (அல்லது அவர் வந்த போக்குவரத்து முறையில் எதுவாக இருந்தாலும், அது ஒரு நொண்டிப் பசுவாக இருந்திருக்கலாம். தினம்.

அன்று மாலை சர்வர் மீண்டும் செயலிழக்கிறது. கதையும் அப்படித்தான்... சர்வர் உயரவில்லை. மார்க் தொலைதூரத்தில் உதவ முயற்சிக்கிறார், ஆனால் கிளையண்ட் சேவையகத்தைத் தொடங்க முடியாது.

மற்றொரு ரயில், பேருந்து, லெமன் மெரிங்கு அல்லது வேறு சில தனம், மற்றும் மார்க் மீண்டும் போர்ட்ஸ்மவுத்தில் இருக்கிறார். பாருங்கள், எந்த பிரச்சனையும் இல்லாமல் சர்வர் பூட் ஆகிறது! அதிசயம். மார்க் பல மணிநேரங்களை ஆப்பரேட்டிங் சிஸ்டம் அல்லது சாஃப்ட்வேருடன் சரிபார்த்து லீட்ஸுக்குப் புறப்படுகிறார்.

நாளின் நடுப்பகுதியில் சர்வர் செயலிழக்கிறது (எளிதாக எடுத்துக் கொள்ளுங்கள்!). இந்த நேரத்தில், சேவையகத்தை மாற்றுவதற்கு வன்பொருள் ஆதரவு நபர்களைக் கொண்டுவருவது நியாயமானதாகத் தெரிகிறது. ஆனால் இல்லை, சுமார் 10 மணி நேரத்திற்குப் பிறகு அது விழுகிறது.

பல நாட்களுக்கு நிலைமை மீண்டும் மீண்டும் வந்தது. சேவையகம் வேலை செய்கிறது, சுமார் 10 மணி நேரத்திற்குப் பிறகு செயலிழக்கச் செய்கிறது மற்றும் அடுத்த 2 மணிநேரத்திற்கு தொடங்காது. அவர்கள் குளிரூட்டல், நினைவக கசிவுகள், எல்லாவற்றையும் சரிபார்த்தனர், ஆனால் எதுவும் கிடைக்கவில்லை. பின்னர் விபத்துகள் நிறுத்தப்பட்டன.

அந்த வாரம் கவலையின்றி கழிந்தது... அனைவரும் மகிழ்ச்சியாக இருந்தனர். எல்லாம் மீண்டும் தொடங்கும் வரை மகிழ்ச்சி. படமும் அப்படியே. 10 மணி நேரம் வேலை, 2-3 மணி நேரம் வேலையில்லா நேரம்...

பின்னர் ஒருவர் (இந்த நபருக்கும் ஐடிக்கும் எந்த தொடர்பும் இல்லை என்று அவர்கள் என்னிடம் சொன்னார்கள் என்று நினைக்கிறேன்) கூறினார்:

"இது அலை!"

ஆச்சரியம் வெற்றுப் பார்வைகளால் எதிர்கொண்டது, மேலும் ஒருவரின் கை பாதுகாப்பு அழைப்பு பட்டனில் தயங்கியிருக்கலாம்.

"இது அலையுடன் வேலை செய்வதை நிறுத்துகிறது."

காபி சாப்பிடும் போது டைட் இயர்புக் படிக்க வாய்ப்பில்லாத IT ஆதரவு தொழிலாளர்களுக்கு இது முற்றிலும் அந்நியமான கருத்தாகத் தோன்றும். ஒரு வாரமாக சர்வர் செயலிழக்காமல் இருந்ததால், இதை எந்த வகையிலும் அலையுடன் தொடர்புபடுத்த முடியாது என்று அவர்கள் விளக்கினர்.

"கடந்த வாரம் அலை குறைவாக இருந்தது, ஆனால் இந்த வாரம் அது அதிகமாக உள்ளது."

படகு உரிமம் இல்லாதவர்களுக்கு ஒரு சிறிய சொல். அலைகள் சந்திர சுழற்சியைப் பொறுத்தது. பூமி சுழலும் போது, ​​ஒவ்வொரு 12,5 மணி நேரத்திற்கும் சூரியன் மற்றும் சந்திரனின் ஈர்ப்பு விசை ஒரு அலை அலையை உருவாக்குகிறது. 12,5 மணி நேர சுழற்சியின் தொடக்கத்தில் ஒரு உயர் அலை உள்ளது, சுழற்சியின் நடுவில் ஒரு ebb உள்ளது, இறுதியில் மீண்டும் ஒரு உயர் அலை உள்ளது. ஆனால் சந்திரனின் சுற்றுப்பாதை மாறும்போது, ​​குறைந்த அலைக்கும் அதிக அலைக்கும் உள்ள வித்தியாசமும் மாறுகிறது. சந்திரன் சூரியனுக்கும் பூமிக்கும் இடையில் அல்லது பூமியின் எதிர் பக்கத்தில் இருக்கும் போது (முழு நிலவு அல்லது சந்திரன் இல்லை), நாம் Syzygyn அலைகளைப் பெறுகிறோம் - மிக உயர்ந்த அலைகள் மற்றும் குறைந்த தாழ்வான அலைகள். அரை நிலவில் நாம் இருபடி அலைகளைப் பெறுகிறோம் - மிகக் குறைந்த அலைகள். இரண்டு உச்சநிலைகளுக்கு இடையிலான வேறுபாடு பெரிதும் குறைகிறது. சந்திர சுழற்சி 28 நாட்கள் நீடிக்கும்: syzygian - quadrature - syzygian - quadrature.

அலை சக்திகளின் சாராம்சத்தை தொழில்நுட்ப வல்லுநர்கள் விளக்கியபோது, ​​​​அவர்கள் உடனடியாக காவல்துறையை அழைக்க வேண்டும் என்று நினைத்தார்கள். மற்றும் மிகவும் தர்க்கரீதியானது. ஆனால் பையன் சொன்னது சரிதான். இரண்டு வாரங்களுக்கு முன்பு, அலுவலகத்திலிருந்து வெகு தொலைவில் ஒரு நாசகார கப்பல் நின்றது. ஒவ்வொரு முறையும் அலை ஒரு குறிப்பிட்ட உயரத்திற்கு அதை உயர்த்தும் போது, ​​கப்பலின் ரேடார் போஸ்ட் சர்வர் அறையின் தரை மட்டத்தில் முடிந்தது. மேலும் ரேடார் (அல்லது மின்னணு போர் உபகரணங்கள், அல்லது வேறு சில இராணுவ பொம்மை) கணினிகளில் குழப்பத்தை உருவாக்கியது.

ராக்கெட்டுக்கான விமான பணி

ஒரு பெரிய (சுமார் 400 ஆயிரம் கோடுகள்) ராக்கெட் ஏவுதல் கட்டுப்பாடு மற்றும் கண்காணிப்பு அமைப்பை இயக்க முறைமை, கம்பைலர் மற்றும் மொழியின் புதிய பதிப்புகளுக்கு அனுப்பும் பணியை நான் பெற்றேன். இன்னும் துல்லியமாக, சோலாரிஸ் 2.5.1 முதல் சோலாரிஸ் 7 வரை மற்றும் அடா 83 இல் எழுதப்பட்ட வெர்டிக்ஸ் அடா டெவலப்மென்ட் சிஸ்டம் (VADS), அடா 95 இல் எழுதப்பட்ட ரேஷனல் அபெக்ஸ் அடா அமைப்பு வரை. VADS ஐ ரேஷனல் வாங்கியது, அதன் தயாரிப்பு வழக்கற்றுப் போனது, இருப்பினும் அபெக்ஸ் கம்பைலருக்கு மாறுவதை எளிதாக்க VADS-குறிப்பிட்ட தொகுப்புகளின் இணக்கமான பதிப்புகளை ரேஷனல் செயல்படுத்த முயற்சித்தது.

குறியீட்டை சுத்தமாக தொகுக்க மூன்று பேர் எனக்கு உதவினார்கள். இரண்டு வாரங்கள் ஆனது. பின்னர் கணினியை வேலை செய்ய நான் சொந்தமாக வேலை செய்தேன். சுருக்கமாக, இது நான் சந்தித்த ஒரு மென்பொருள் அமைப்பின் மோசமான கட்டமைப்பு மற்றும் செயல்படுத்தல், எனவே துறைமுகத்தை முடிக்க இன்னும் இரண்டு மாதங்கள் ஆனது. இந்த அமைப்பு பின்னர் சோதனைக்கு சமர்ப்பிக்கப்பட்டது, இது இன்னும் பல மாதங்கள் எடுத்தது. சோதனையின் போது கண்டறியப்பட்ட பிழைகளை நான் உடனடியாக சரிசெய்தேன், ஆனால் அவற்றின் எண்ணிக்கை விரைவாகக் குறைந்தது (மூலக் குறியீடு ஒரு உற்பத்தி அமைப்பு, எனவே அதன் செயல்பாடு மிகவும் நம்பகத்தன்மையுடன் செயல்பட்டது, புதிய கம்பைலருக்குத் தழுவலின் போது எழுந்த பிழைகளை நான் அகற்ற வேண்டியிருந்தது). இறுதியில், எல்லாம் சரியாக வேலை செய்யும் போது, ​​​​நான் வேறு திட்டத்திற்கு மாற்றப்பட்டேன்.

நன்றி செலுத்துவதற்கு முந்தைய வெள்ளிக்கிழமை, தொலைபேசி ஒலித்தது.

ராக்கெட் ஏவுதல் சுமார் மூன்று வாரங்களில் சோதிக்கப்பட வேண்டும், மேலும் கவுண்டவுனின் ஆய்வக சோதனைகளின் போது, ​​கட்டளைகளின் வரிசை தடுக்கப்பட்டது. நிஜ வாழ்க்கையில், இது சோதனையை நிறுத்தும், மேலும் இயந்திரத்தைத் தொடங்கிய சில நொடிகளில் அடைப்பு ஏற்பட்டால், துணை அமைப்புகளில் பல மாற்ற முடியாத செயல்கள் ஏற்படும், இதற்கு ராக்கெட்டின் நீண்ட மற்றும் விலையுயர்ந்த தயார்நிலை தேவைப்படும். இது தொடங்கியிருக்காது, ஆனால் நிறைய பேர் நேரம் மற்றும் நிறைய பணம் இழப்பு பற்றி மிகவும் வருத்தப்பட்டிருப்பார்கள். பாதுகாப்புத் துறை பொறுப்பற்ற முறையில் பணத்தைச் செலவழிக்கிறது என்று யாரும் உங்களுக்குச் சொல்ல வேண்டாம் - பட்ஜெட்டை முதலாவதாகவோ அல்லது இரண்டாவதாகவோ, அதைத் தொடர்ந்து அட்டவணையை வைக்காத ஒப்பந்த மேலாளரை நான் சந்தித்ததில்லை.

முந்தைய மாதங்களில், இந்த கவுண்ட்டவுன் சவால் பல மாறுபாடுகளில் நூற்றுக்கணக்கான முறை இயக்கப்பட்டது, சில சிறிய விக்கல்கள் மட்டுமே இருந்தன. எனவே இது நிகழும் வாய்ப்பு மிகவும் குறைவாக இருந்தது, ஆனால் அதன் விளைவுகள் மிகவும் குறிப்பிடத்தக்கவை. இந்த இரண்டு காரணிகளையும் பெருக்கவும், எனக்கும் டஜன் கணக்கான பொறியாளர்கள் மற்றும் மேலாளர்களுக்கும் ஒரு பாழடைந்த விடுமுறை வாரத்தை செய்தி கணித்துள்ளது என்பதை நீங்கள் புரிந்துகொள்வீர்கள்.

கணினியை போர்ட் செய்த நபராக எனக்கு கவனம் செலுத்தப்பட்டது.

பெரும்பாலான பாதுகாப்பு-முக்கிய அமைப்புகளைப் போலவே, பல அளவுருக்கள் பதிவு செய்யப்பட்டுள்ளன, எனவே கணினி செயலிழக்கப்படுவதற்கு முன்பு செயல்படுத்தப்பட்ட குறியீட்டின் சில வரிகளை அடையாளம் காண்பது மிகவும் எளிதானது. நிச்சயமாக, அவற்றில் அசாதாரணமானது எதுவும் இல்லை; அதே வெளிப்பாடுகள் ஒரே ஓட்டத்தின் போது ஆயிரக்கணக்கான முறை வெற்றிகரமாக செயல்படுத்தப்பட்டன.

கம்பைலரை உருவாக்கியவர்கள் மற்றும் அவர்கள் உருவாக்கிய சில நடைமுறைகள் சந்தேகத்திற்கிடமான குறியீட்டில் அழைக்கப்பட்டதால், அபெக்ஸில் உள்ளவர்களை நாங்கள் பகுத்தறிவு என்று அழைத்தோம். உண்மையில் தேசிய முக்கியத்துவம் வாய்ந்த ஒரு பிரச்சனையின் மூலத்தைப் பெற வேண்டிய அவசியம் இருப்பதாக அவர்கள் (மற்றும் மற்ற அனைவரும்) ஈர்க்கப்பட்டனர்.

பத்திரிகைகளில் சுவாரஸ்யமான எதுவும் இல்லாததால், உள்ளூர் ஆய்வகத்தில் சிக்கலை மீண்டும் உருவாக்க முயற்சிக்க முடிவு செய்தோம். இந்த நிகழ்வு 1000 ரன்களுக்கு ஒரு முறை நடந்ததால் இது எளிதான காரியம் அல்ல. ஒரு சந்தேகத்திற்குரிய காரணம், விற்பனையாளரால் உருவாக்கப்பட்ட மியூடெக்ஸ் செயல்பாட்டிற்கான அழைப்பு (VADS இடம்பெயர்வு தொகுப்பின் ஒரு பகுதி) Unlock திறப்பதற்கு வழிவகுக்கவில்லை. செயல்பாடு என்று அழைக்கப்படும் செயலாக்க நூல் இதய துடிப்பு செய்திகளை செயலாக்கியது, இது பெயரளவில் ஒவ்வொரு நொடியும் வந்தது. அதிர்வெண்ணை 10 ஹெர்ட்ஸாக, அதாவது வினாடிக்கு 10 முறை உயர்த்தி, இயங்கத் தொடங்கினோம். சுமார் ஒரு மணி நேரம் கழித்து, கணினி தானாகவே பூட்டப்பட்டது. பதிவில், பதிவுசெய்யப்பட்ட செய்திகளின் வரிசை தோல்வியுற்ற சோதனையின் போது இருந்ததைப் போலவே இருப்பதைக் கண்டோம். நாங்கள் இன்னும் பல ஓட்டங்களைச் செய்தோம், தொடக்கத்திற்குப் பிறகு 45-90 நிமிடங்களுக்குப் பிறகு கணினி தொடர்ந்து தடுக்கப்பட்டது, மேலும் ஒவ்வொரு முறையும் பதிவில் ஒரே பாதை இருந்தது. நாங்கள் தொழில்நுட்ப ரீதியாக வெவ்வேறு குறியீட்டை இயக்கினாலும் - செய்தி அதிர்வெண் வேறுபட்டது - கணினியின் நடத்தை ஒரே மாதிரியாக இருந்தது, எனவே இந்த சுமை காட்சி அதே சிக்கலை ஏற்படுத்துகிறது என்று நாங்கள் நம்பினோம்.

வெளிப்பாடுகளின் வரிசையில் எங்கு தடுப்பு ஏற்பட்டது என்பதை இப்போது நாம் கண்டுபிடிக்க வேண்டும்.

அமைப்பின் இந்த செயல்படுத்தல் அடா டாஸ்க் சிஸ்டத்தைப் பயன்படுத்தியது, மேலும் அதை நம்பமுடியாத அளவிற்கு மோசமாகப் பயன்படுத்தியது. பணிகள் என்பது அடாவில் ஒரே நேரத்தில் இயங்கக்கூடிய உயர்நிலை கட்டமைப்பாகும், இது செயல்படுத்தும் நூல்கள் போன்றது, மொழியில் மட்டுமே கட்டமைக்கப்பட்டுள்ளது. இரண்டு பணிகள் தொடர்பு கொள்ள வேண்டிய அவசியம் ஏற்பட்டால், அவை "ஒரு சந்திப்பை அமைத்து", தேவையான தரவைப் பரிமாறி, பின்னர் சந்திப்பை நிறுத்திவிட்டு அவற்றின் சுயாதீனமான செயல்பாட்டிற்குத் திரும்புகின்றன. இருப்பினும், அமைப்பு வேறுபட்ட முறையில் செயல்படுத்தப்பட்டது. ஒரு இலக்கு பணி சந்திப்புக்கு பிறகு, அந்த இலக்கு பணி மற்றொரு பணியுடன் சந்திப்பு செய்யப்பட்டது, அது மூன்றாவது பணியுடன் சந்திப்பு, மற்றும் சில செயலாக்கம் முடியும் வரை. இதற்குப் பிறகு, இந்த சந்திப்புகள் அனைத்தும் முடிக்கப்பட்டன, மேலும் ஒவ்வொரு பணியும் அதன் செயல்பாட்டிற்கு திரும்ப வேண்டும். அதாவது, நாங்கள் உலகின் மிக விலையுயர்ந்த செயல்பாட்டு அழைப்பு அமைப்பைக் கையாளுகிறோம், இது உள்ளீட்டுத் தரவின் ஒரு பகுதியை செயலாக்கும் போது முழு "பல்பணி" செயல்முறையையும் நிறுத்தியது. இதற்கு முன், செயல்திறன் மிகக் குறைவாக இருந்ததால் மட்டுமே சிக்கல்களுக்கு வழிவகுக்கவில்லை.

நான் இந்த பணி பொறிமுறையை விவரித்தேன், ஏனெனில் ஒரு சந்திப்பு கோரப்பட்டால் அல்லது முடிவடையும் என்று எதிர்பார்க்கப்படும் போது, ​​"பணி மாறுதல்" ஏற்படலாம். அதாவது, செயலி செயல்படுத்தத் தயாராக இருக்கும் மற்றொரு பணியைச் செயலாக்கத் தொடங்கலாம். ஒரு பணி மற்றொரு பணியுடன் சந்திப்பதற்குத் தயாராக இருக்கும்போது, ​​முற்றிலும் மாறுபட்ட பணியை செயல்படுத்தத் தொடங்கலாம், இறுதியில் முதல் சந்திப்புக்குத் திரும்புவதைக் கட்டுப்படுத்தலாம். மேலும் பணி மாறுவதற்கு காரணமான பிற நிகழ்வுகள் நிகழலாம்; அத்தகைய நிகழ்வுகளில் ஒன்று மியூடெக்ஸை அச்சிடுதல் அல்லது செயல்படுத்துதல் போன்ற கணினி செயல்பாட்டிற்கான அழைப்பு.

எந்த கோட் கோடு சிக்கலை ஏற்படுத்துகிறது என்பதைப் புரிந்து கொள்ள, ஒரு செயலிழப்பைத் தடுக்கும் ஒரு பணி மாறுதலைத் தூண்டாமல் அறிக்கைகளின் வரிசையின் மூலம் முன்னேற்றத்தைப் பதிவு செய்வதற்கான வழியைக் கண்டுபிடிக்க வேண்டும். அதனால் என்னால் பயன்பெற முடியவில்லை Put_Line()I/O செயல்பாடுகளைச் செய்வதைத் தவிர்க்க. நான் ஒரு எதிர் மாறி அல்லது அது போன்ற ஏதாவது ஒன்றை அமைக்க முடியும், ஆனால் என்னால் அதை திரையில் காட்ட முடியாவிட்டால் அதன் மதிப்பை எப்படி பார்க்க முடியும்?

மேலும், பதிவை ஆய்வு செய்யும் போது, ​​இதயத்துடிப்பு செய்திகளின் செயலாக்கத்தில் முடக்கம் இருந்தபோதிலும், செயல்முறையின் அனைத்து I/O செயல்பாடுகளையும் தடுத்து மற்ற செயலாக்கங்களைச் செய்வதைத் தடுக்கிறது, பிற சுயாதீனமான பணிகள் தொடர்ந்து செயல்படுத்தப்பட்டன. அதாவது, வேலை முற்றிலும் தடுக்கப்படவில்லை, ஒரு (முக்கியமான) பணிகளின் சங்கிலி மட்டுமே.

தடுக்கும் வெளிப்பாட்டை மதிப்பிடுவதற்குத் தேவையான துப்பு இதுவாகும்.

நான் ஒரு அடா தொகுப்பை உருவாக்கினேன், அதில் ஒரு பணி, கணக்கிடப்பட்ட வகை மற்றும் அந்த வகையின் உலகளாவிய மாறி உள்ளது. சிக்கலான வரிசையின் குறிப்பிட்ட வெளிப்பாடுகளுக்கு எண்ணிலடங்கா எழுத்துக்கள் பிணைக்கப்பட்டுள்ளன (எ.கா. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), பின்னர் அதில் அசைன்மென்ட் எக்ஸ்ப்ரெஷன்களைச் செருகியது, அது உலகளாவிய மாறிக்கு தொடர்புடைய கணக்கீட்டை ஒதுக்கியது. இவை அனைத்தின் பொருள் குறியீடு நினைவகத்தில் ஒரு மாறிலியை சேமித்து வைத்திருப்பதால், அதன் செயல்பாட்டின் விளைவாக பணி மாறுதல் மிகவும் சாத்தியமில்லை. பணியை மாற்றக்கூடிய வெளிப்பாடுகளை நாங்கள் முதன்மையாக சந்தேகிக்கிறோம், ஏனெனில் பணியை மீண்டும் மாற்றும்போது (பல காரணங்களுக்காக) திரும்புவதற்குப் பதிலாக செயல்படுத்தும்போது தடுப்பு ஏற்பட்டது.

கண்காணிப்பு பணியானது ஒரு சுழற்சியில் இயங்கி, உலகளாவிய மாறியின் மதிப்பு மாறிவிட்டதா என்று அவ்வப்போது சரிபார்க்கப்பட்டது. ஒவ்வொரு மாற்றத்திலும், மதிப்பு ஒரு கோப்பில் சேமிக்கப்பட்டது. பின்னர் ஒரு சிறிய காத்திருப்பு மற்றும் ஒரு புதிய காசோலை. நான் கோப்பில் மாறியை எழுதினேன், ஏனெனில் சிக்கல் பகுதியில் பணியை மாற்றும்போது கணினி அதை செயல்படுத்துவதற்குத் தேர்ந்தெடுக்கும்போது மட்டுமே பணி செயல்படுத்தப்பட்டது. இந்தப் பணியில் என்ன நடந்தாலும் அது தொடர்பில்லாத தடுக்கப்பட்ட பணிகளைப் பாதிக்காது.

கணினி சிக்கலான குறியீட்டை இயக்கும் நிலையை அடைந்ததும், ஒவ்வொரு அடுத்த வெளிப்பாட்டிற்கும் நகரும் போது உலகளாவிய மாறி மீட்டமைக்கப்படும் என்று எதிர்பார்க்கப்பட்டது. பின்னர் ஏதாவது நடக்கும், இது பணி மாறுவதற்கு காரணமாகிறது, மேலும் அதன் செயலாக்க அதிர்வெண் (10 ஹெர்ட்ஸ்) கண்காணிப்பு பணியை விட குறைவாக இருப்பதால், மானிட்டர் உலகளாவிய மாறியின் மதிப்பைப் பிடித்து அதை எழுத முடியும். ஒரு சாதாரண சூழ்நிலையில், கணக்கீடுகளின் துணைக்குழுவின் தொடர்ச்சியான வரிசையை என்னால் பெற முடியும்: பணி மாறும்போது மாறியின் கடைசி மதிப்புகள். தொங்கும் போது, ​​உலகளாவிய மாறி இனி மாறக்கூடாது, கடைசியாக எழுதப்பட்ட மதிப்பு எந்த வெளிப்பாடு முழுமையடையவில்லை என்பதைக் குறிக்கும்.

நான் கண்காணிப்புடன் குறியீட்டை இயக்கினேன். அவன் உறைந்து போனான். மற்றும் கண்காணிப்பு கடிகார வேலை போல் வேலை செய்தது.

பதிவில் எதிர்பார்க்கப்படும் வரிசை உள்ளது, இது ஒரு மியூடெக்ஸ் அழைக்கப்பட்டதைக் குறிக்கும் மதிப்பால் குறுக்கிடப்பட்டது Unlock, மற்றும் பணி முடிக்கப்படவில்லை - ஆயிரக்கணக்கான முந்தைய அழைப்புகளைப் போலவே.

இந்த நேரத்தில் அபெக்ஸ் பொறியாளர்கள் தங்கள் குறியீட்டை தீவிரமாக பகுப்பாய்வு செய்து கொண்டிருந்தனர் மற்றும் கோட்பாட்டளவில், ஒரு பூட்டு ஏற்படக்கூடிய ஒரு இடத்தை மியூடெக்ஸில் கண்டறிந்தனர். ஆனால் அதன் நிகழ்தகவு மிகவும் குறைவாக இருந்தது, ஏனெனில் ஒரு குறிப்பிட்ட நேரத்தில் நிகழும் நிகழ்வுகளின் ஒரு குறிப்பிட்ட வரிசை மட்டுமே தடுக்க வழிவகுக்கும். மர்பியின் சட்டம், நண்பர்களே, இது மர்பியின் சட்டம்.

எனக்குத் தேவையான குறியீட்டின் பகுதியைப் பாதுகாக்க, மியூடெக்ஸ் செயல்பாடு அழைப்புகளை (OS மியூடெக்ஸ் செயல்பாட்டின் மேல் கட்டப்பட்டது) மாற்றியமைத்தேன், அந்தத் துண்டிற்கான மியூடெக்ஸ் அணுகலைக் கட்டுப்படுத்த ஒரு சிறிய சொந்த அடா மியூடெக்ஸ் தொகுப்பை மாற்றினேன்.

நான் அதை குறியீட்டில் செருகி சோதனையை நடத்தினேன். ஏழு மணி நேரம் கழித்து குறியீடு இன்னும் வேலை செய்தது.

எனது குறியீடு பகுத்தறிவுக்குச் சமர்ப்பிக்கப்பட்டது, அங்கு அவர்கள் அதைத் தொகுத்து, பிரித்தெடுத்தனர், மேலும் சிக்கலான மியூடெக்ஸ் செயல்பாடுகளில் பயன்படுத்தப்பட்ட அதே அணுகுமுறையைப் பயன்படுத்தவில்லை என்பதைச் சரிபார்த்தனர்.

இது எனது தொழில் வாழ்க்கையில் மிகவும் நெரிசலான குறியீடு மதிப்பாய்வு ஆகும்

குறியீடு மதிப்பாய்வு செய்யப்பட்டது, புதிய இயங்கக்கூடிய கோப்புகள் சேகரிக்கப்பட்டு முறையான பின்னடைவு சோதனைக்காக சமர்ப்பிக்கப்பட்டன. இரண்டு வாரங்களுக்குப் பிறகு, கவுண்டவுன் சோதனை வெற்றிகரமாக இருந்தது மற்றும் ராக்கெட் புறப்பட்டது.

சரி, அதெல்லாம் நன்றாக இருக்கிறது, ஆனால் கதையின் பயன் என்ன?

இது முற்றிலும் கேவலமான பிரச்சனையாக இருந்தது. நூறாயிரக்கணக்கான கோடுகள், இணையான செயலாக்கம், ஒரு டஜன் ஊடாடும் செயல்முறைகள், மோசமான கட்டிடக்கலை மற்றும் மோசமான செயல்படுத்தல், உட்பொதிக்கப்பட்ட அமைப்புகளுக்கான இடைமுகங்கள் மற்றும் மில்லியன் கணக்கான டாலர்கள் செலவழிக்கப்பட்டன. அழுத்தம் இல்லை, சரி.

இந்த பிரச்சனையில் நான் மட்டும் வேலை செய்யவில்லை, இருப்பினும் நான் போர்டிங் செய்வதால் கவனத்தை ஈர்த்தேன். ஆனால் நான் அதைச் செய்திருந்தாலும், நூறாயிரக்கணக்கான கோடுகளை நான் புரிந்துகொண்டேன் அல்லது அவற்றைக் குறைத்தேன் என்று அர்த்தமல்ல. குறியீடு மற்றும் பதிவுகள் நாடு முழுவதும் உள்ள பொறியாளர்களால் பகுப்பாய்வு செய்யப்பட்டன, ஆனால் தோல்விக்கான காரணங்களைப் பற்றிய அவர்களின் கருதுகோள்களை என்னிடம் சொன்னபோது, ​​​​அவற்றை மறுக்க எனக்கு அரை நிமிடம் ஆனது. கோட்பாடுகளை பகுப்பாய்வு செய்யும்படி என்னிடம் கேட்கப்பட்டபோது, ​​​​நான் அதை வேறொருவருக்கு அனுப்புவேன், ஏனென்றால் இந்த பொறியாளர்கள் தவறான வழியில் செல்கிறார்கள் என்பது எனக்குத் தெளிவாகத் தெரிந்தது. ஆணவமாக இருக்கிறதா? ஆம், இது உண்மைதான், ஆனால் மற்றொரு காரணத்திற்காக நான் கருதுகோள்களையும் கோரிக்கைகளையும் நிராகரித்தேன்.

பிரச்சனையின் தன்மை எனக்குப் புரிந்தது. இது எங்கு நடக்கிறது அல்லது ஏன் நடக்கிறது என்று எனக்குத் தெரியவில்லை, ஆனால் என்ன நடக்கிறது என்று எனக்குத் தெரியும்.

பல ஆண்டுகளாக, நான் நிறைய அறிவையும் அனுபவத்தையும் குவித்துள்ளேன். அடாவைப் பயன்படுத்துவதற்கான முன்னோடிகளில் நானும் ஒருவன், அதன் நன்மைகள் மற்றும் தீமைகளைப் புரிந்துகொண்டேன். அடா இயக்க நேர நூலகங்கள் எவ்வாறு பணிகளைக் கையாளுகின்றன மற்றும் இணையான செயலாக்கத்தை எவ்வாறு கையாள்கின்றன என்பதை நான் அறிவேன். நினைவகம், பதிவுகள் மற்றும் அசெம்பிளர் மட்டத்தில் குறைந்த அளவிலான நிரலாக்கத்தை நான் புரிந்துகொள்கிறேன். வேறு வார்த்தைகளில் கூறுவதானால், எனது துறையில் எனக்கு ஆழ்ந்த அறிவு உள்ளது. பிரச்சனைக்கான காரணத்தைக் கண்டறிய நான் அவற்றைப் பயன்படுத்தினேன். நான் பிழையைச் சுற்றி வேலை செய்யவில்லை, மிகவும் உணர்திறன் வாய்ந்த இயக்க நேர சூழலில் அதை எவ்வாறு கண்டுபிடிப்பது என்பதை நான் புரிந்துகொண்டேன்.

அத்தகைய போராட்டத்தின் அம்சங்கள் மற்றும் நிலைமைகளை நன்கு அறிந்திராதவர்களுக்கு, குறியீட்டுடனான போராட்டத்தின் இத்தகைய கதைகள் மிகவும் சுவாரஸ்யமாக இருக்காது. ஆனால் இந்த கதைகள் உண்மையில் கடினமான பிரச்சனைகளை தீர்க்க என்ன செய்ய வேண்டும் என்பதைப் புரிந்துகொள்ள உதவுகிறது.

மிகவும் கடினமான சிக்கல்களைத் தீர்க்க, நீங்கள் ஒரு புரோகிராமராக இருக்க வேண்டும். குறியீட்டின் "விதி", அதன் சுற்றுச்சூழலுடன் எவ்வாறு தொடர்பு கொள்கிறது மற்றும் சுற்றுச்சூழல் எவ்வாறு செயல்படுகிறது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும்.

பின்னர் உங்கள் சொந்த பாழடைந்த விடுமுறை வாரம் உங்களுக்கு இருக்கும்.

தொடர வேண்டும்.

ஆதாரம்: www.habr.com