బగ్‌లు కొన్నిసార్లు పూర్తిగా నమ్మశక్యం కాని వ్యక్తీకరణలను ఎలా కలిగి ఉంటాయి అనే దాని గురించి ఇంటర్నెట్ నుండి కథనాల ఎంపిక ఇది. బహుశా మీరు కూడా చెప్పడానికి ఏదైనా ఉండవచ్చు.
వెనీలా ఐస్‌క్రీమ్‌కి కారు ఎలర్జీ
స్పష్టమైనది ఎల్లప్పుడూ సమాధానం కాదని మరియు వాస్తవాలు ఎంత వింతగా అనిపించినా అవి ఇప్పటికీ వాస్తవాలు అని అర్థం చేసుకునే ఇంజనీర్ల కోసం ఒక కథ. జనరల్ మోటార్స్ కార్పొరేషన్ యొక్క పోంటియాక్ డివిజన్ ఫిర్యాదును అందుకుంది:
నేను మీకు ఇది రెండవసారి వ్రాస్తున్నాను మరియు సమాధానం ఇవ్వనందుకు నేను మిమ్మల్ని నిందించను, ఎందుకంటే ఇది పిచ్చిగా అనిపిస్తుంది. మా కుటుంబంలో రోజూ రాత్రి భోజనం తర్వాత ఐస్‌క్రీమ్‌ తినే సంప్రదాయం ఉంది. ఐస్ క్రీం రకాలు ప్రతిసారీ మారుతూ ఉంటాయి మరియు రాత్రి భోజనం తర్వాత, కుటుంబం మొత్తం ఏ ఐస్ క్రీం కొనాలో ఎంచుకుంటుంది, ఆ తర్వాత నేను దుకాణానికి వెళ్తాను. నేను ఇటీవల కొత్త పోంటియాక్‌ని కొనుగోలు చేసాను మరియు అప్పటి నుండి ఐస్ క్రీం పొందడానికి నా పర్యటనలు సమస్యగా మారాయి. నేను వెనీలా ఐస్ క్రీం కొని, దుకాణం నుండి తిరిగి వచ్చిన ప్రతిసారీ, కారు స్టార్ట్ అవ్వదు. మరేదైనా ఐస్ క్రీం తీసుకువస్తే, ఎలాంటి ఇబ్బంది లేకుండా కారు స్టార్ట్ అవుతుంది. నేను గంభీరమైన ప్రశ్న అడగాలనుకుంటున్నాను, అది ఎంత తెలివితక్కువదని అనిపించినా: “నేను వనిల్లా ఐస్‌క్రీం తెచ్చినప్పుడు అది స్టార్ట్ కాకుండా, నేను ఐస్‌క్రీం యొక్క మరొక రుచిని తీసుకురాగానే సులభంగా ప్రారంభించేలా చేసే పోంటియాక్ గురించి ఏమిటి?” "
మీరెవరో ఊహించినట్లుగానే ఆ లేఖపై డివిజన్ అధ్యక్షుడికి అనుమానం వచ్చింది. అయితే, నేను తనిఖీ చేయడానికి ఇంజనీర్‌ను పంపాను. ఒక అందమైన ప్రాంతంలో నివసించే ధనవంతుడు, బాగా చదువుకున్న వ్యక్తి తనను కలవడం అతనికి ఆశ్చర్యం కలిగించింది. ఇద్దరూ ఐస్ క్రీం కోసం దుకాణానికి వెళ్లడానికి రాత్రి భోజనం చేసిన వెంటనే కలుసుకోవాలని వారు అంగీకరించారు. ఆ సాయంత్రం అది వెనీలా, మరియు వారు తిరిగి కారు వద్దకు వచ్చినప్పుడు, అది స్టార్ట్ కాలేదు.
ఇంజనీర్ మరో మూడు సాయంత్రం వచ్చాడు. మొదటిసారి ఐస్ క్రీం చాక్లెట్. కారు స్టార్ట్ చేసింది. రెండవసారి స్ట్రాబెర్రీ ఐస్ క్రీం ఉంది. కారు స్టార్ట్ చేసింది. మూడో రోజు సాయంత్రం వెనీలా తీసుకోమని అడిగాడు. కారు స్టార్ట్ కాలేదు.
హేతుబద్ధంగా వాదిస్తూ, కారుకు వెనీలా ఐస్‌క్రీమ్‌కు అలెర్జీ ఉందని నమ్మడానికి ఇంజనీర్ నిరాకరించాడు. అందువల్ల, సమస్యకు పరిష్కారం కనుగొనే వరకు అతను తన సందర్శనలను కొనసాగిస్తానని కారు యజమానితో నేను అంగీకరించాను. మరియు మార్గంలో, అతను నోట్స్ తీసుకోవడం ప్రారంభించాడు: అతను అన్ని సమాచారం, రోజు సమయం, గ్యాసోలిన్ రకం, దుకాణం నుండి వచ్చిన మరియు తిరిగి వచ్చే సమయం మొదలైనవాటిని వ్రాసాడు.
కారు యజమాని వెనిలా ఐస్ క్రీం కొనడానికి తక్కువ సమయం వెచ్చించాడని ఇంజనీర్ వెంటనే గ్రహించాడు. కారణం దుకాణంలో వస్తువుల లేఅవుట్. వెనిలా ఐస్ క్రీం అత్యంత ప్రాచుర్యం పొందింది మరియు సులభంగా కనుగొనడానికి స్టోర్ ముందు భాగంలో ప్రత్యేక ఫ్రీజర్‌లో ఉంచబడింది. మరియు అన్ని ఇతర రకాలు స్టోర్ వెనుక భాగంలో ఉన్నాయి మరియు సరైన రకాన్ని కనుగొని చెల్లించడానికి చాలా ఎక్కువ సమయం పట్టింది.
ఇప్పుడు ప్రశ్న ఇంజనీర్ కోసం ఉంది: ఇంజిన్ ఆపివేయబడిన క్షణం నుండి తక్కువ సమయం గడిచినట్లయితే కారు ఎందుకు ప్రారంభించలేదు? సమస్య సమయం మరియు వనిల్లా ఐస్ క్రీం కాదు కాబట్టి, ఇంజనీర్ త్వరగా సమాధానం కనుగొన్నాడు: ఇది గ్యాస్ లాక్. ఇది ప్రతి సాయంత్రం జరుగుతుంది, కానీ కారు యజమాని ఐస్ క్రీం కోసం వెతకడానికి ఎక్కువ సమయం గడిపినప్పుడు, ఇంజిన్ తగినంతగా చల్లబరుస్తుంది మరియు సులభంగా ప్రారంభించబడింది. మరియు మనిషి వనిల్లా ఐస్ క్రీం కొనుగోలు చేసినప్పుడు, ఇంజిన్ ఇప్పటికీ చాలా వేడిగా ఉంది మరియు గ్యాస్ లాక్ కరిగిపోయే సమయం లేదు.
నీతి: పూర్తిగా వెర్రి సమస్యలు కూడా కొన్నిసార్లు నిజమైనవి.
క్రాష్ పందికొక్కు
దీన్ని అనుభవించడం బాధాకరం. ప్రోగ్రామర్‌గా, మీరు మీ కోడ్‌ను మొదటి, రెండవ, మూడవ... మరియు ఎక్కడో పదివేల స్థానంలో కంపైలర్‌ని నిందించటం అలవాటు చేసుకుంటారు. మరియు జాబితాలో మీరు ఇప్పటికే పరికరాలను నిందిస్తారు.
హార్డ్‌వేర్ బగ్ గురించి నా కథనం ఇక్కడ ఉంది.
క్రాష్ బాండికూట్ గేమ్ కోసం, నేను మెమరీ కార్డ్‌లో లోడ్ చేయడానికి మరియు సేవ్ చేయడానికి కోడ్‌ని వ్రాసాను. అటువంటి స్మగ్ గేమ్ డెవలపర్ కోసం, ఇది పార్క్‌లో నడవడం లాంటిది: పనికి చాలా రోజులు పడుతుందని నేను అనుకున్నాను. అయితే, నేను ఆరు వారాల పాటు కోడ్‌ని డీబగ్ చేయడం ముగించాను. అలాగే, నేను ఇతర సమస్యలను పరిష్కరించాను, కానీ ప్రతి కొన్ని రోజులకు నేను కొన్ని గంటలపాటు ఈ కోడ్‌కి తిరిగి వచ్చాను. ఇది వేదన.
ఈ లక్షణం ఇలా కనిపించింది: మీరు గేమ్ యొక్క ప్రస్తుత ప్లేత్రూని సేవ్ చేసి, మెమరీ కార్డ్‌ని యాక్సెస్ చేసినప్పుడు, ప్రతిదీ దాదాపు ఎల్లప్పుడూ బాగానే ఉంటుంది... కానీ కొన్నిసార్లు ఎటువంటి స్పష్టమైన కారణం లేకుండానే రీడ్ లేదా రైట్ ఆపరేషన్ సమయం ముగిసింది. చిన్న రికార్డింగ్ తరచుగా మెమరీ కార్డ్‌ను దెబ్బతీస్తుంది. ఒక ఆటగాడు సేవ్ చేయడానికి ప్రయత్నించినప్పుడు, అతను సేవ్ చేయడంలో విఫలమవ్వడమే కాకుండా, మ్యాప్‌ను కూడా నాశనం చేస్తాడు. చెత్త.
కాసేపటి తర్వాత, సోనీలో మా నిర్మాత, కొన్నీ బస్‌కి భయాందోళనలు మొదలయ్యాయి. మేము ఈ బగ్‌తో గేమ్‌ను షిప్ చేయలేకపోయాము మరియు ఆరు వారాల తర్వాత సమస్యకు కారణమేమిటో నాకు అర్థం కాలేదు. కొన్నీ ద్వారా, మేము ఇతర PS1 డెవలపర్‌లను సంప్రదించాము: ఎవరైనా ఇలాంటిదేదైనా ఎదుర్కొన్నారా? నం. మెమరీ కార్డ్‌తో ఎవరికీ సమస్యలు లేవు.
డీబగ్గింగ్ కోసం మీకు ఆలోచనలు లేనప్పుడు, "విభజించి జయించడం" మాత్రమే మిగిలి ఉంది: సమస్యకు కారణమయ్యే సాపేక్షంగా చిన్న భాగం మిగిలిపోయే వరకు తప్పు ప్రోగ్రామ్ నుండి మరింత ఎక్కువ కోడ్‌ను తీసివేయండి. అంటే, బగ్‌ను కలిగి ఉన్న భాగం మిగిలిపోయే వరకు మీరు ప్రోగ్రామ్‌ను ముక్కగా కత్తిరించండి.
కానీ విషయం ఏమిటంటే, వీడియో గేమ్ నుండి భాగాలను కత్తిరించడం చాలా కష్టం. మీరు గురుత్వాకర్షణను అనుకరించే కోడ్‌ను తీసివేస్తే దాన్ని ఎలా అమలు చేయాలి? లేదా అక్షరాలు గీయడం?
అందువల్ల, మేము ఉపయోగకరమైన ఏదైనా చేసినట్లు నటించే స్టబ్‌లతో మొత్తం మాడ్యూల్‌లను భర్తీ చేయాలి, అయితే వాస్తవానికి లోపాలను కలిగి ఉండని చాలా సరళమైనదాన్ని చేయాలి. ఆటకు కనీసం పని చేయాలంటే మనం ఇలాంటి ఊతకర్రలు రాయాలి. ఇది నెమ్మదిగా మరియు బాధాకరమైన ప్రక్రియ.
సంక్షిప్తంగా, నేను చేసాను. గేమ్‌ను అమలు చేయడానికి సిస్టమ్‌ను కాన్ఫిగర్ చేసే, రెండరింగ్ హార్డ్‌వేర్‌ను ప్రారంభించడం మొదలైన ప్రారంభ కోడ్‌తో మిగిలిపోయే వరకు నేను మరిన్ని ఎక్కువ కోడ్ ముక్కలను తీసివేసాను. వాస్తవానికి, ఈ దశలో నేను సేవ్ మరియు లోడ్ మెనుని సృష్టించలేకపోయాను, ఎందుకంటే నేను అన్ని గ్రాఫిక్స్ కోడ్‌ల కోసం స్టబ్‌ని సృష్టించాలి. కానీ నేను (అదృశ్య) సేవ్ మరియు లోడ్ స్క్రీన్‌ని ఉపయోగించి వినియోగదారుగా నటిస్తాను మరియు సేవ్ చేయమని అడగవచ్చు మరియు మెమరీ కార్డ్‌కి వ్రాయవచ్చు.
ఇది ఇప్పటికీ పై సమస్యను కలిగి ఉన్న చిన్న కోడ్ ముక్కను నాకు మిగిల్చింది - కానీ ఇది ఇప్పటికీ యాదృచ్ఛికంగా జరుగుతోంది! చాలా తరచుగా ప్రతిదీ బాగా పనిచేసింది, కానీ అప్పుడప్పుడు అవాంతరాలు ఉన్నాయి. నేను దాదాపు మొత్తం గేమ్ కోడ్‌ని తీసివేసాను, కానీ బగ్ ఇంకా సజీవంగానే ఉంది. ఇది అస్పష్టంగా ఉంది: మిగిలిన కోడ్ నిజానికి ఏమీ చేయలేదు.
ఏదో ఒక సమయంలో, బహుశా తెల్లవారుజామున మూడు గంటలకు, నాకు ఒక ఆలోచన వచ్చింది. చదవడం మరియు వ్రాయడం (ఇన్‌పుట్/అవుట్‌పుట్) కార్యకలాపాలు ఖచ్చితమైన అమలు సమయాలను కలిగి ఉంటాయి. మీరు హార్డ్ డ్రైవ్, మెమరీ కార్డ్ లేదా బ్లూటూత్ మాడ్యూల్‌తో పని చేస్తున్నప్పుడు, చదవడానికి మరియు వ్రాయడానికి బాధ్యత వహించే తక్కువ-స్థాయి కోడ్ క్లాక్ పల్స్‌కు అనుగుణంగా పని చేస్తుంది.
గడియారం సహాయంతో, ప్రాసెసర్‌కు నేరుగా కనెక్ట్ చేయబడని పరికరం ప్రాసెసర్‌లో అమలు చేసే కోడ్‌తో సమకాలీకరించబడుతుంది. గడియారం బాడ్ రేటును నిర్ణయిస్తుంది-డేటా ప్రసారం చేసే వేగం. సమయాలలో గందరగోళం ఉంటే, హార్డ్‌వేర్ లేదా సాఫ్ట్‌వేర్ లేదా రెండూ కూడా గందరగోళానికి గురవుతాయి. మరియు ఇది చాలా చెడ్డది, ఎందుకంటే డేటా దెబ్బతింటుంది.
మన కోడ్‌లోని ఏదైనా సమయాలను గందరగోళానికి గురిచేస్తే? నేను పరీక్ష ప్రోగ్రామ్ కోడ్‌లో దీనికి సంబంధించిన ప్రతిదాన్ని తనిఖీ చేసాను మరియు మేము ప్రోగ్రామబుల్ టైమర్‌ను PS1 నుండి 1 kHz (సెకనుకు 1000 టిక్‌లు)కి సెట్ చేసినట్లు గమనించాను. ఇది చాలా ఎక్కువ; డిఫాల్ట్‌గా, కన్సోల్ ప్రారంభమైనప్పుడు, అది 100 Hz వద్ద నడుస్తుంది. మరియు చాలా ఆటలు ఈ ఫ్రీక్వెన్సీని ఉపయోగిస్తాయి.
ఆండీ, గేమ్ డెవలపర్, టైమర్‌ను 1 kHzకి సెట్ చేయండి, తద్వారా కదలికలు మరింత ఖచ్చితంగా గణించబడతాయి. ఆండీ ఓవర్‌బోర్డ్‌కు వెళ్లడానికి ఇష్టపడతారు మరియు మేము గురుత్వాకర్షణను అనుకరిస్తే, మేము దానిని సాధ్యమైనంత ఖచ్చితంగా చేస్తాము!
అయితే టైమర్‌ను వేగవంతం చేయడం వల్ల ప్రోగ్రామ్ యొక్క మొత్తం సమయాన్ని ఏదో ఒకవిధంగా ప్రభావితం చేసి, మెమొరీ కార్డ్ కోసం బాడ్ రేటును నియంత్రించే గడియారం ఏ విధంగా ఉంటుంది?
నేను టైమర్ కోడ్‌ని వ్యాఖ్యానించాను. పొరపాటు మళ్లీ జరగలేదు. కానీ మేము దీన్ని పరిష్కరించామని దీని అర్థం కాదు, ఎందుకంటే వైఫల్యం యాదృచ్ఛికంగా సంభవించింది. నేను అదృష్టవంతుడైతే?
కొన్ని రోజుల తర్వాత నేను పరీక్ష ప్రోగ్రామ్‌తో మళ్లీ ప్రయోగాలు చేశాను. బగ్ పునరావృతం కాలేదు. నేను పూర్తి గేమ్ కోడ్‌బేస్‌కి తిరిగి వెళ్లి సేవ్ మరియు లోడ్ కోడ్‌ని సవరించాను, తద్వారా మెమొరీ కార్డ్‌ని యాక్సెస్ చేయడానికి ముందు ప్రోగ్రామబుల్ టైమర్ దాని అసలు విలువ (100Hz)కి రీసెట్ చేయబడుతుంది, ఆపై తిరిగి 1kHzకి రీసెట్ చేయబడుతుంది. ఇక క్రాష్‌లు లేవు.
అయితే ఇది ఎందుకు జరిగింది?
నేను మళ్ళీ పరీక్ష కార్యక్రమానికి తిరిగి వచ్చాను. నేను 1 kHz టైమర్‌తో లోపం సంభవించినప్పుడు కొంత నమూనాను కనుగొనడానికి ప్రయత్నించాను. ఎవరైనా PS1 కంట్రోలర్‌తో ఆడినప్పుడు లోపం సంభవిస్తుందని చివరికి నేను గమనించాను. నేను దీన్ని చాలా అరుదుగా చేస్తాను కాబట్టి - సేవ్ మరియు లోడ్ కోడ్‌ను పరీక్షించేటప్పుడు నాకు కంట్రోలర్ ఎందుకు అవసరం? - నేను ఈ ఆధారపడటాన్ని కూడా గమనించలేదు. కానీ ఒకరోజు మా ఆర్టిస్టులలో ఒకరు నేను పరీక్ష ముగించే వరకు వేచి ఉన్నారు - నేను బహుశా ఆ సమయంలో శపించాను - మరియు భయంతో అతని చేతిలోని కంట్రోలర్‌ను తిప్పాడు. ఒక లోపము సంభవించినది. "ఆగండి, ఏమిటి?!" సరే, మళ్ళీ చెయ్యి!"
ఈ రెండు ఈవెంట్‌లు పరస్పరం అనుసంధానించబడి ఉన్నాయని నేను గ్రహించినప్పుడు, నేను లోపాన్ని సులభంగా పునరుత్పత్తి చేయగలిగాను: నేను మెమరీ కార్డ్‌కి రికార్డింగ్ చేయడం ప్రారంభించాను, కంట్రోలర్‌ను తరలించాను మరియు మెమరీ కార్డ్‌ను నాశనం చేసాను. నాకు అది హార్డ్‌వేర్ బగ్ లాగా అనిపించింది.
నేను కొన్నీకి వచ్చి నా ఆవిష్కరణ గురించి చెప్పాను. PS1ని రూపొందించిన ఇంజనీర్లలో ఒకరికి ఆమె సమాచారాన్ని చేరవేసింది. "అసాధ్యం," అతను బదులిచ్చారు, "ఇది హార్డ్‌వేర్ సమస్య కాదు." మా కోసం సంభాషణను ఏర్పాటు చేయమని నేను కోనీని అడిగాను.
ఇంజనీర్ నన్ను పిలిచాడు మరియు మేము అతని విరిగిన ఆంగ్లంలో మరియు నా (అత్యంత) విరిగిన జపనీస్‌లో వాదించాము. చివరగా నేను, "కంట్రోలర్‌ను తరలించడం బగ్‌కు కారణమయ్యే నా 30 లైన్ టెస్ట్ ప్రోగ్రామ్‌ను పంపనివ్వండి." అతను అంగీకరించాడు. ఇది సమయం వృధా అని మరియు అతను కొత్త ప్రాజెక్ట్‌లో పనిలో చాలా బిజీగా ఉన్నాడని, అయితే మేము సోనీకి చాలా ముఖ్యమైన డెవలపర్‌గా ఉన్నందున లొంగిపోతానని చెప్పాడు. నేను నా పరీక్ష ప్రోగ్రామ్‌ను శుభ్రం చేసి అతనికి పంపాను.
మరుసటి రోజు సాయంత్రం (మేము లాస్ ఏంజిల్స్‌లో ఉన్నాము మరియు అతను టోక్యోలో ఉన్నాడు) అతను నన్ను పిలిచి క్షమాపణలు చెప్పాడు. ఇది హార్డ్‌వేర్ సమస్య.
సరిగ్గా బగ్ ఏమిటో నాకు తెలియదు, కానీ నేను సోనీ ప్రధాన కార్యాలయంలో విన్న దాని నుండి, మీరు టైమర్‌ను తగినంత అధిక విలువకు సెట్ చేస్తే, అది టైమర్ క్రిస్టల్ సమీపంలో ఉన్న మదర్‌బోర్డ్‌లోని భాగాలకు అంతరాయం కలిగిస్తుంది. వాటిలో ఒకటి మెమరీ కార్డ్ కోసం బాడ్ రేట్ కంట్రోలర్, ఇది కంట్రోలర్‌లకు బాడ్ రేట్‌ను కూడా సెట్ చేస్తుంది. నేను ఇంజనీర్‌ని కాదు, కాబట్టి నేను ఏదో గొడవ చేసి ఉండవచ్చు.
కానీ బాటమ్ లైన్ ఏమిటంటే మదర్‌బోర్డులోని భాగాల మధ్య జోక్యం ఉంది. మరియు 1 kHz వద్ద నడుస్తున్న టైమర్‌తో కంట్రోలర్ పోర్ట్ మరియు మెమరీ కార్డ్ పోర్ట్ ద్వారా డేటాను ఏకకాలంలో ప్రసారం చేస్తున్నప్పుడు, బిట్‌లు పోయాయి, డేటా పోయింది మరియు కార్డ్ పాడైంది.
చెడ్డ ఆవులు
1980లలో, నా గురువు సెర్గీ PDP-1800 యొక్క సోవియట్ క్లోన్ అయిన SM-11 కోసం సాఫ్ట్‌వేర్ రాశారు. ఈ మైక్రోకంప్యూటర్ USSRలోని ఒక ముఖ్యమైన రవాణా కేంద్రమైన Sverdlovsk సమీపంలోని రైల్వే స్టేషన్‌లో ఇప్పుడే ఇన్స్టాల్ చేయబడింది. కొత్త వ్యవస్థ వ్యాగన్లను మరియు సరుకు రవాణాను రూట్ చేయడానికి రూపొందించబడింది. కానీ ఇది యాదృచ్ఛిక క్రాష్‌లు మరియు క్రాష్‌లకు దారితీసిన బాధించే బగ్‌ని కలిగి ఉంది. ఎవరైనా సాయంత్రం ఇంటికి వెళ్లినప్పుడు ఎప్పుడూ జలపాతం సంభవించింది. కానీ మరుసటి రోజు సమగ్ర విచారణ ఉన్నప్పటికీ, కంప్యూటర్ అన్ని మాన్యువల్ మరియు ఆటోమేటిక్ పరీక్షలలో సరిగ్గా పని చేసింది. ఇది సాధారణంగా నిర్దిష్ట పరిస్థితులలో సంభవించే జాతి పరిస్థితి లేదా కొన్ని ఇతర పోటీ బగ్‌ని సూచిస్తుంది. అర్థరాత్రి కాల్‌లతో విసిగిపోయి, సెర్గీ దాని దిగువకు వెళ్లాలని నిర్ణయించుకున్నాడు మరియు మొదటగా, మార్షలింగ్ యార్డ్‌లోని పరిస్థితులు కంప్యూటర్ విచ్ఛిన్నానికి దారితీశాయో అర్థం చేసుకోండి.
మొదట, అతను అన్ని వివరించలేని జలపాతాల గణాంకాలను సేకరించాడు మరియు తేదీ మరియు సమయం ఆధారంగా గ్రాఫ్‌ను సృష్టించాడు. నమూనా స్పష్టంగా కనిపించింది. మరికొన్ని రోజులు పరిశీలించిన తర్వాత, భవిష్యత్తులో సిస్టమ్ వైఫల్యాల సమయాన్ని తాను సులభంగా అంచనా వేయగలనని సెర్గీ గ్రహించాడు.
స్టేషన్ ఉత్తర ఉక్రెయిన్ మరియు పశ్చిమ రష్యా నుండి సమీపంలోని కబేళాకు వెళ్లే రైలు లోడ్‌లను క్రమబద్ధీకరించేటప్పుడు మాత్రమే అంతరాయాలు సంభవించాయని అతను త్వరలోనే తెలుసుకున్నాడు. ఇది వింతగా ఉంది, ఎందుకంటే కజాఖ్‌స్థాన్‌లో కబేళా చాలా దగ్గరగా ఉన్న పొలాల ద్వారా సరఫరా చేయబడింది.
చెర్నోబిల్ న్యూక్లియర్ పవర్ ప్లాంట్ 1986లో పేలింది మరియు రేడియోధార్మిక పతనం పరిసర ప్రాంతాలను నివాసయోగ్యంగా మార్చింది. ఉత్తర ఉక్రెయిన్, బెలారస్ మరియు పశ్చిమ రష్యాలోని విస్తారమైన ప్రాంతాలు కలుషితమయ్యాయి. వచ్చే క్యారేజీలలో అధిక స్థాయి రేడియేషన్ ఉందని అనుమానిస్తూ, సెర్గీ ఈ సిద్ధాంతాన్ని పరీక్షించడానికి ఒక పద్ధతిని అభివృద్ధి చేశాడు. జనాభా డోసిమీటర్‌లను కలిగి ఉండకుండా నిషేధించబడింది, కాబట్టి సెర్గీ రైల్వే స్టేషన్‌లో అనేక మంది సైనికులతో తనను తాను నమోదు చేసుకున్నాడు. అనేక వోడ్కా పానీయాల తర్వాత, అతను అనుమానాస్పద క్యారేజీలలో ఒకదానిలో రేడియేషన్ స్థాయిని కొలవడానికి ఒక సైనికుడిని ఒప్పించగలిగాడు. సాధారణ విలువల కంటే స్థాయి చాలా రెట్లు ఎక్కువ అని తేలింది.
పశువులు చాలా రేడియేషన్‌ను విడుదల చేయడమే కాదు, దాని స్థాయి చాలా ఎక్కువగా ఉంది, ఇది స్టేషన్ పక్కన ఉన్న భవనంలో ఉన్న SM-1800 యొక్క మెమరీలో యాదృచ్ఛికంగా బిట్‌లను కోల్పోయేలా చేసింది.
USSR లో ఆహార కొరత ఉంది మరియు దేశంలోని ఇతర ప్రాంతాల నుండి వచ్చిన మాంసంతో చెర్నోబిల్ మాంసాన్ని కలపాలని అధికారులు నిర్ణయించారు. విలువైన వనరులను కోల్పోకుండా రేడియోధార్మికత యొక్క మొత్తం స్థాయిని తగ్గించడం ఇది సాధ్యపడింది. దీని గురించి తెలుసుకున్న సెర్గీ వెంటనే వలస కోసం పత్రాలను నింపాడు. మరియు కాలక్రమేణా రేడియేషన్ స్థాయి తగ్గినప్పుడు కంప్యూటర్ క్రాష్‌లు వాటంతట అవే ఆగిపోయాయి.
పైపుల ద్వారా
ఒకప్పుడు, మూవీటెక్ సొల్యూషన్స్ సినిమాల కోసం సాఫ్ట్‌వేర్‌ను రూపొందించింది, ఇది అకౌంటింగ్, టికెట్ అమ్మకాలు మరియు సాధారణ నిర్వహణ కోసం రూపొందించబడింది. ఫ్లాగ్‌షిప్ యాప్ యొక్క DOS వెర్షన్ ఉత్తర అమెరికాలోని చిన్న మరియు మధ్య తరహా సినిమా థియేటర్ చైన్‌లలో బాగా ప్రాచుర్యం పొందింది. కాబట్టి Windows 95 సంస్కరణను ప్రకటించినప్పుడు, తాజా టచ్ స్క్రీన్‌లు మరియు స్వీయ-సేవ కియోస్క్‌లతో అనుసంధానించబడినప్పుడు మరియు అన్ని రకాల రిపోర్టింగ్ టూల్స్‌తో అమర్చబడినప్పుడు, ఇది త్వరగా ప్రజాదరణ పొందడంలో ఆశ్చర్యం లేదు. చాలా తరచుగా నవీకరణ సమస్యలు లేకుండా పోయింది. స్థానిక IT సిబ్బంది కొత్త పరికరాలను ఇన్స్టాల్ చేసారు, డేటాను బదిలీ చేసారు మరియు వ్యాపారం కొనసాగింది. అది కొనసాగనప్పుడు తప్ప. ఇది జరిగినప్పుడు, కంపెనీ "ది క్లీనర్" అనే మారుపేరుతో జేమ్స్‌ను బయటకు పంపుతుంది.
మారుపేరు దుర్మార్గపు రకాన్ని సూచిస్తున్నప్పటికీ, క్లీనర్ అనేది బోధకుడు, ఇన్‌స్టాలర్ మరియు జాక్-ఆఫ్-ఆల్-ట్రేడ్‌ల కలయిక మాత్రమే. జేమ్స్ క్లయింట్ యొక్క సైట్‌లో అన్ని భాగాలను ఒకచోట చేర్చి కొన్ని రోజులు గడిపాడు, ఆపై కొత్త సిస్టమ్‌ను ఎలా ఉపయోగించాలో సిబ్బందికి బోధించడం, ఏవైనా హార్డ్‌వేర్ సమస్యలను పరిష్కరించడం మరియు సాఫ్ట్‌వేర్ దాని బాల్యంలో తప్పనిసరిగా సహాయం చేయడం వంటి వాటిని మరో రెండు రోజులు గడిపాడు.
అందువల్ల, ఈ రద్దీ సమయాల్లో, జేమ్స్ ఉదయాన్నే కార్యాలయానికి చేరుకోవడంలో ఆశ్చర్యం లేదు, మరియు అతను తన డెస్క్‌కి చేరుకోకముందే, మామూలు కంటే కెఫిన్‌తో నిండిన మేనేజర్ అతన్ని అభినందించాడు.
"మీరు వీలైనంత త్వరగా అన్నాపోలిస్, నోవా స్కోటియాకు వెళ్లాలని నేను భయపడుతున్నాను." వారి మొత్తం వ్యవస్థ క్షీణించింది మరియు వారి ఇంజనీర్‌లతో ఒక రాత్రి పని చేసిన తర్వాత, ఏమి జరిగిందో మేము గుర్తించలేము. సర్వర్‌లో నెట్‌వర్క్ విఫలమైనట్లు కనిపిస్తోంది. కానీ సిస్టమ్ చాలా నిమిషాల పాటు రన్ అయిన తర్వాత మాత్రమే.
- వారు పాత వ్యవస్థకు తిరిగి రాలేదా? - మానసికంగా అతను ఆశ్చర్యంతో కళ్ళు పెద్దవి చేసుకున్నప్పటికీ, జేమ్స్ పూర్తిగా తీవ్రంగా సమాధానం చెప్పాడు.
— సరిగ్గా: వారి IT నిపుణుడు "ప్రాధాన్యాలను మార్చారు" మరియు వారి పాత సర్వర్‌తో బయలుదేరాలని నిర్ణయించుకున్నారు. జేమ్స్, వారు ఆరు సైట్‌లలో సిస్టమ్‌ను ఇన్స్టాల్ చేసారు మరియు ప్రీమియం మద్దతు కోసం చెల్లించారు మరియు వారి వ్యాపారం ఇప్పుడు 1950ల మాదిరిగానే నడుస్తుంది.
జేమ్స్ కొద్దిగా నిటారుగా ఉన్నాడు.
- అది వేరే విషయం. సరే, ప్రారంభిద్దాం.
అతను అన్నాపోలిస్‌కు వచ్చినప్పుడు, అతను చేసిన మొదటి పని సమస్య ఉన్న కస్టమర్ యొక్క మొదటి థియేటర్‌ను కనుగొనడం. ఎయిర్‌పోర్ట్‌లో తీసిన మ్యాప్‌లో అన్నీ డీసెంట్‌గా కనిపించాయి, కానీ కోరుకున్న చిరునామా చుట్టూ ఉన్న ప్రాంతం అనుమానాస్పదంగా కనిపించింది. ఘెట్టో కాదు, ఫిలిం నోయర్‌ని గుర్తుకు తెస్తుంది. జేమ్స్ కాలిబాట డౌన్‌టౌన్ వద్ద పార్క్ చేస్తున్నప్పుడు, ఒక వేశ్య అతనిని సమీపించింది. అన్నాపోలిస్ పరిమాణాన్ని బట్టి, ఇది మొత్తం నగరంలో ఒకే ఒక్కటి కావచ్చు. ఆమె ప్రదర్శన వెంటనే పెద్ద తెరపై డబ్బు కోసం సెక్స్ అందించే ప్రసిద్ధ పాత్రను గుర్తుకు తెచ్చింది. లేదు, జూలియా రాబర్ట్స్ గురించి కాదు, కానీ జోన్ వోయిట్ గురించి ["మిడ్నైట్ కౌబాయ్" చిత్రానికి సూచన - సుమారు. వీధి].
వేశ్యను ఆమె మార్గంలో పంపిన తరువాత, జేమ్స్ సినిమాకి వెళ్ళాడు. చుట్టుపక్కల ప్రాంతం మెరుగుపడింది, కానీ అది ఇప్పటికీ పడిపోయిన భావనను ఇచ్చింది. జేమ్స్ చాలా ఆందోళన చెందాడని కాదు. అతను ఇంతకు ముందు అధ్వాన్నమైన ప్రదేశాలకు వెళ్ళాడు. మరియు ఇది కెనడా, ఇక్కడ మగ్గర్లు కూడా మీ వాలెట్ తీసుకున్న తర్వాత "ధన్యవాదాలు" అని చెప్పేంత మర్యాదగా ఉంటారు.
సినిమాకి ప్రక్క ప్రవేశ ద్వారం ఒక చీకటి సందులో ఉంది. జేమ్స్ తలుపు దగ్గరకు వెళ్లి కొట్టాడు. కొద్దిసేపటికే అది క్రీక్ చేసి కొద్దిగా తెరుచుకుంది.
-మీరు క్లీనర్‌లా? - లోపల నుండి ఒక గద్గద స్వరం వచ్చింది.
- అవును, ఇది నేనే... నేను ప్రతిదీ సరిచేయడానికి వచ్చాను.
జేమ్స్ సినిమా లాబీలోకి వెళ్లాడు. స్పష్టంగా వేరే మార్గం లేకపోవడంతో, సిబ్బంది సందర్శకులకు పేపర్ టిక్కెట్లను అందజేయడం ప్రారంభించారు. ఇది ఆర్థిక రిపోర్టింగ్‌ను కష్టతరం చేసింది, మరిన్ని ఆసక్తికరమైన వివరాలు మాత్రమే. కానీ సిబ్బంది జేమ్స్‌ను రిలీఫ్‌గా పలకరించి వెంటనే సర్వర్ రూమ్‌కి తీసుకెళ్లారు.
మొదటి చూపులో, ప్రతిదీ బాగానే ఉంది. జేమ్స్ సర్వర్‌లోకి లాగిన్ అయ్యాడు మరియు సాధారణ అనుమానాస్పద స్థలాలను తనిఖీ చేశాడు. ఏమి ఇబ్బంది లేదు. అయినప్పటికీ, చాలా జాగ్రత్తతో, జేమ్స్ సర్వర్‌ను మూసివేసి, నెట్‌వర్క్ కార్డ్‌ను భర్తీ చేసి, సిస్టమ్‌ను వెనక్కి తీసుకున్నాడు. ఆమె వెంటనే పూర్తి స్థాయిలో పని చేయడం ప్రారంభించింది. సిబ్బంది మళ్లీ టిక్కెట్ల విక్రయం ప్రారంభించారు.
జేమ్స్ మార్క్‌కి ఫోన్ చేసి పరిస్థితిని తెలియజేశాడు. ఊహించని విధంగా ఏదైనా జరిగితే చూడాలని జేమ్స్ కోరుకోవచ్చని ఊహించడం కష్టం కాదు. అతను మెట్లు దిగి ఉద్యోగులను ఏమి జరిగిందో అడగడం ప్రారంభించాడు. స్పష్టంగా, సిస్టమ్ పనిచేయడం ఆగిపోయింది. వారు దాన్ని ఆపివేసారు మరియు ఆన్ చేసారు, ప్రతిదీ పని చేసింది. కానీ 10 నిమిషాల తర్వాత సిస్టమ్ పడిపోయింది.
ఈ తరుణంలో అలాంటిదే జరిగింది. అకస్మాత్తుగా, టికెటింగ్ సిస్టమ్ లోపాలను విసరడం ప్రారంభించింది. సిబ్బంది ఊపిరి పీల్చుకుని పేపర్ టిక్కెట్లు పట్టుకుని, జేమ్స్ సర్వర్ రూమ్‌కి హడావిడిగా వెళ్లాడు. సర్వర్‌తో అంతా బాగానే ఉంది.
అప్పుడు ఒక ఉద్యోగి లోపలికి వచ్చాడు.
- సిస్టమ్ మళ్లీ పని చేస్తోంది.
అతను ఏమీ చేయనందున జేమ్స్ అయోమయంలో పడ్డాడు. మరింత ఖచ్చితంగా, సిస్టమ్ పని చేసేలా ఏమీ లేదు. అతను లాగ్ అవుట్ చేసి, తన ఫోన్‌ని తీసుకుని, తన కంపెనీ సపోర్ట్ లైన్‌కి కాల్ చేసాడు. వెంటనే అదే ఉద్యోగి సర్వర్ గదిలోకి ప్రవేశించాడు.
- సిస్టమ్ డౌన్ అయింది.
జేమ్స్ సర్వర్ వైపు చూశాడు. బహుళ-రంగు ఆకారాల యొక్క ఆసక్తికరమైన మరియు సుపరిచితమైన నమూనా తెరపై నృత్యం చేసింది - అస్తవ్యస్తంగా మెలికలు తిరుగుతూ మరియు పెనవేసుకున్న పైపులు. మనమందరం ఈ స్క్రీన్‌సేవర్‌ని ఏదో ఒక సమయంలో చూశాము. ఇది అందంగా అన్వయించబడింది మరియు అక్షరాలా హిప్నోటైజింగ్ చేయబడింది.
జేమ్స్ ఒక బటన్‌ను నొక్కినప్పుడు ఆ నమూనా కనిపించకుండా పోయింది. అతను టికెట్ కార్యాలయానికి త్వరితంగా వెళ్లి, దారిలో తన వద్దకు తిరిగి వస్తున్న ఒక ఉద్యోగిని కలిశాడు.
- సిస్టమ్ మళ్లీ పని చేస్తోంది.
మీరు మెంటల్ ఫేస్‌పామ్ చేయగలిగితే, జేమ్స్ చేసినది అదే. స్క్రీన్సేవర్. ఇది OpenGLని ఉపయోగిస్తుంది. అందువలన, ఆపరేషన్ సమయంలో, ఇది సర్వర్ ప్రాసెసర్ యొక్క అన్ని వనరులను వినియోగిస్తుంది. ఫలితంగా, సర్వర్‌కి చేసే ప్రతి కాల్ గడువుతో ముగుస్తుంది.
జేమ్స్ సర్వర్ గదికి తిరిగి వచ్చాడు, లాగిన్ చేసి, స్క్రీన్‌సేవర్‌ను అందమైన పైపులతో ఖాళీ స్క్రీన్‌తో భర్తీ చేశాడు. అంటే, 100% ప్రాసెసర్ వనరులను వినియోగించే స్క్రీన్‌సేవర్‌కు బదులుగా, వనరులను వినియోగించని మరొకదాన్ని నేను ఇన్స్టాల్ చేసాను. అప్పుడు నేను నా అంచనాను తనిఖీ చేయడానికి 10 నిమిషాలు వేచి ఉన్నాను.
జేమ్స్ తదుపరి సినిమా వద్దకు వచ్చినప్పుడు, స్క్రీన్ సేవర్‌ను ఆఫ్ చేయడానికి తాను కేవలం 800 కి.మీ ప్రయాణించానని తన మేనేజర్‌కి ఎలా వివరించాలని ఆలోచిస్తున్నాడు.
చంద్రుని యొక్క నిర్దిష్ట దశలో క్రాష్
నిజమైన కథ. ఒకరోజు చంద్రుని దశపై ఆధారపడిన సాఫ్ట్‌వేర్ బగ్ తలెత్తింది. చంద్రుని యొక్క నిజమైన దశకు ఉజ్జాయింపును లెక్కించడానికి వివిధ MIT ప్రోగ్రామ్‌లలో సాధారణంగా ఉపయోగించే చిన్న రొటీన్ ఉంది. GLS ఈ రొటీన్‌ను LISP ప్రోగ్రామ్‌గా రూపొందించింది, ఇది ఫైల్‌ను వ్రాసేటప్పుడు దాదాపు 80 అక్షరాల పొడవు గల టైమ్‌స్టాంప్‌తో లైన్‌ను అవుట్‌పుట్ చేస్తుంది. సందేశం యొక్క మొదటి పంక్తి చాలా పొడవుగా ఉండి, తదుపరి పంక్తికి దారితీయడం చాలా అరుదు. మరియు ప్రోగ్రామ్ తరువాత ఈ ఫైల్‌ను చదివినప్పుడు, అది శపించింది. మొదటి పంక్తి యొక్క పొడవు ఖచ్చితమైన తేదీ మరియు సమయంపై ఆధారపడి ఉంటుంది, అలాగే టైమ్‌స్టాంప్ ముద్రించిన సమయంలో దశ వివరణ యొక్క పొడవు. అంటే, బగ్ అక్షరాలా చంద్రుని దశపై ఆధారపడి ఉంటుంది!
మొదటి పేపర్ ఎడిషన్ (Steele-1983) వివరించిన బగ్‌కు దారితీసిన అటువంటి లైన్ యొక్క ఉదాహరణను కలిగి ఉంది, కానీ టైప్‌సెట్టర్ దానిని "పరిష్కరించింది". ఇది "మూన్ ఫేజ్ బగ్"గా వర్ణించబడింది.
అయితే, అంచనాలతో జాగ్రత్తగా ఉండండి. కొన్ని సంవత్సరాల క్రితం, CERN (యూరోపియన్ సెంటర్ ఫర్ న్యూక్లియర్ రీసెర్చ్) నుండి ఇంజనీర్లు లార్జ్ ఎలక్ట్రాన్-పాసిట్రాన్ కొలైడర్ వద్ద చేసిన ప్రయోగాలలో లోపాలను ఎదుర్కొన్నారు. శాస్త్రవేత్తలకు ఫలితాన్ని చూపించే ముందు ఈ పరికరం ద్వారా ఉత్పత్తి చేయబడిన అపారమైన డేటాను కంప్యూటర్లు చురుకుగా ప్రాసెస్ చేస్తాయి కాబట్టి, సాఫ్ట్‌వేర్ చంద్రుని దశకు ఏదో ఒకవిధంగా సున్నితంగా ఉంటుందని చాలా మంది ఊహించారు. చాలా మంది నిరాశకు గురైన ఇంజనీర్లు నిజం దిగువకు వచ్చారు. చంద్రుడు వెళ్లే సమయంలో భూమి వైకల్యంతో 27 కి.మీ పొడవున్న వలయం జ్యామితిలో స్వల్ప మార్పు కారణంగా ఈ లోపం తలెత్తింది! ఈ కథ భౌతిక శాస్త్ర జానపద కథలలో "న్యూటన్ యొక్క రివెంజ్ ఆన్ పార్టికల్ ఫిజిక్స్"గా ప్రవేశించింది మరియు భౌతిక శాస్త్రం యొక్క సరళమైన మరియు పురాతన నియమాలు మరియు అత్యంత అధునాతన శాస్త్రీయ భావనల మధ్య సంబంధానికి ఉదాహరణ.
టాయిలెట్‌ను ఫ్లష్ చేయడం వల్ల రైలు ఆగిపోతుంది
నేను విన్న అత్యుత్తమ హార్డ్‌వేర్ బగ్ ఫ్రాన్స్‌లోని హై స్పీడ్ రైలులో ఉంది. బగ్ రైలు యొక్క అత్యవసర బ్రేకింగ్‌కు దారితీసింది, కానీ విమానంలో ప్రయాణీకులు ఉన్నట్లయితే మాత్రమే. అటువంటి ప్రతి సందర్భంలో, రైలు సేవ నుండి తీసివేయబడింది, తనిఖీ చేయబడింది, కానీ ఏమీ కనుగొనబడలేదు. అప్పుడు అతను లైన్‌కు తిరిగి పంపబడ్డాడు మరియు అతను వెంటనే ఆపివేయబడ్డాడు.
తనిఖీల్లో భాగంగా రైలులో ప్రయాణిస్తున్న ఓ ఇంజనీర్ టాయిలెట్‌కు వెళ్లాడు. అతను వెంటనే కొట్టుకుపోయాడు, బూమ్! అత్యసవర నిలుపుదల.
ఇంజనీర్ డ్రైవర్‌ని సంప్రదించి ఇలా అడిగాడు:
- బ్రేకింగ్ చేయడానికి ముందు మీరు ఏమి చేస్తున్నారు?
- బాగా, నేను అవరోహణలో వేగాన్ని తగ్గించాను ...
ఇది వింతగా ఉంది, ఎందుకంటే సాధారణ ఆపరేషన్ సమయంలో రైలు డజన్ల కొద్దీ అవరోహణలపై వేగాన్ని తగ్గిస్తుంది. రైలు ముందుకు సాగింది మరియు తదుపరి దిగేటప్పుడు డ్రైవర్ హెచ్చరించాడు:
- నేను వేగాన్ని తగ్గించబోతున్నాను.
ఏమీ జరగలేదు.
— చివరి బ్రేకింగ్ సమయంలో మీరు ఏమి చేసారు? - అడిగాడు డ్రైవర్.
- సరే... నేను టాయిలెట్‌లో ఉన్నాను...
- సరే, అప్పుడు టాయిలెట్‌కి వెళ్లి, మేము మళ్లీ కిందకు వెళ్లినప్పుడు మీరు చేసిన పనిని చేయండి!
ఇంజనీర్ టాయిలెట్‌కి వెళ్ళాడు, మరియు డ్రైవర్ హెచ్చరించినప్పుడు: "నేను వేగాన్ని తగ్గించాను," అతను నీటిని ఫ్లష్ చేసాడు. అయితే, రైలు వెంటనే ఆగిపోయింది.
ఇప్పుడు వారు సమస్యను పునరుత్పత్తి చేయగలరు మరియు కారణాన్ని కనుగొనవలసి ఉంటుంది.
రెండు నిమిషాల తర్వాత, ఇంజిన్ బ్రేక్ రిమోట్ కంట్రోల్ కేబుల్ (రైలుకు ప్రతి చివర ఒక ఇంజిన్ ఉంటుంది) ఎలక్ట్రికల్ క్యాబినెట్ గోడ నుండి డిస్‌కనెక్ట్ చేయబడిందని మరియు టాయిలెట్ ప్లగ్ సోలనోయిడ్‌ను నియంత్రించే రిలేపై పడుకోవడం వారు గమనించారు... రిలే చేసినప్పుడు ఆన్ చేయబడింది, ఇది బ్రేక్ కేబుల్‌లో జోక్యాన్ని సృష్టించింది మరియు వైఫల్యాలకు వ్యతిరేకంగా సిస్టమ్ రక్షణ అత్యవసర బ్రేకింగ్‌ను కలిగి ఉంటుంది.
ఫోర్ట్రాన్‌ను అసహ్యించుకునే గేట్‌వే
కొన్ని నెలల క్రితం ప్రధాన భూభాగంలో [ఇది హవాయిలో] నెట్‌వర్క్ కనెక్షన్‌లు చాలా నెమ్మదిగా జరుగుతున్నాయని మేము గమనించాము. ఇది 10-15 నిమిషాల పాటు కొనసాగవచ్చు మరియు అకస్మాత్తుగా మళ్లీ సంభవించవచ్చు. కొంత సమయం తరువాత, ప్రధాన భూభాగంలో నెట్‌వర్క్ కనెక్షన్‌లు ఉన్నాయని నా సహోద్యోగి నాకు ఫిర్యాదు చేశాడు సాధారణంగా పని చేయదు. అతను మెయిన్‌ల్యాండ్‌లోని మెషీన్‌కు కాపీ చేయవలసిన కొన్ని ఫోర్ట్రాన్ కోడ్‌ని కలిగి ఉన్నాడు, కానీ అది కుదరలేదు ఎందుకంటే "FTP అప్‌లోడ్ పూర్తి చేయడానికి నెట్‌వర్క్ ఎక్కువసేపు పట్టుకోలేదు."
అవును, ఒక సహోద్యోగి FORTRANలోని సోర్స్ కోడ్‌తో కూడిన ఫైల్‌ను ప్రధాన భూభాగంలోని మెషీన్‌కు FTP చేయడానికి ప్రయత్నించినప్పుడు నెట్‌వర్క్ వైఫల్యాలు సంభవించాయని తేలింది. మేము ఫైల్‌ను ఆర్కైవ్ చేయడానికి ప్రయత్నించాము: అది సజావుగా కాపీ చేయబడింది (కానీ లక్ష్య యంత్రానికి అన్‌ప్యాకర్ లేదు, కాబట్టి సమస్య పరిష్కరించబడలేదు). చివరగా మేము FORTRAN కోడ్‌ను చాలా చిన్న ముక్కలుగా "విభజిస్తాము" మరియు వాటిని ఒక్కొక్కటిగా పంపాము. చాలా శకలాలు సమస్యలు లేకుండా కాపీ చేయబడ్డాయి, కానీ కొన్ని ముక్కలు పాస్ కాలేదు, లేదా పాస్ కాలేదు అనేక ప్రయత్నాలు.
సమస్యాత్మక భాగాలను పరిశీలించిన తర్వాత, వాటికి ఉమ్మడిగా ఏదో ఉందని మేము కనుగొన్నాము: అవన్నీ క్యాపిటల్ C (FORTRANలో వ్యాఖ్యానించడానికి ఇష్టపడే సహోద్యోగి వలె) పంక్తులతో ప్రారంభమైన మరియు ముగిసే వ్యాఖ్య బ్లాక్‌లను కలిగి ఉన్నాయి. మేము ప్రధాన భూభాగంలోని నెట్‌వర్క్ నిపుణులకు ఇమెయిల్ పంపాము మరియు సహాయం కోసం అడిగాము. అయితే, వారు FTP ద్వారా బదిలీ చేయలేని మా ఫైల్‌ల నమూనాలను చూడాలనుకున్నారు... కానీ మా లేఖలు వారికి చేరలేదు. చివరగా మేము ఒక సాధారణ ఆలోచనతో వచ్చాము వివరించండిబదిలీ చేయలేని ఫైల్‌లు ఎలా ఉంటాయి. ఇది పనిచేసింది :) [సమస్యాత్మకమైన ఫోర్ట్రాన్ వ్యాఖ్యలలో ఒకదానికి ఉదాహరణను నేను ఇక్కడ జోడించాలనుకుంటున్నారా? బహుశా అది విలువైనది కాదు!]
చివరికి మేము దానిని గుర్తించగలిగాము. క్యాంపస్‌లోని మా భాగం మరియు మెయిన్‌ల్యాండ్ నెట్‌వర్క్ మధ్య కొత్త గేట్‌వే ఇటీవల ఇన్స్టాల్ చేయబడింది. పెద్ద అక్షరం C యొక్క పునరావృత బిట్‌లను కలిగి ఉన్న ప్యాకెట్‌లను ప్రసారం చేయడంలో ఇది చాలా ఇబ్బందిని కలిగి ఉంది! ఈ ప్యాకెట్‌లలో కొన్ని మాత్రమే అన్ని గేట్‌వే వనరులను తీసుకుంటాయి మరియు చాలా ఇతర ప్యాకెట్‌లను పొందకుండా నిరోధించగలవు. మేము గేట్‌వే తయారీదారుకి ఫిర్యాదు చేసాము... మరియు వారు ఇలా సమాధానమిచ్చారు: “ఓహ్, అవును, మీరు పునరావృతమయ్యే C యొక్క బగ్‌ను ఎదుర్కొంటున్నారు! అతని గురించి మాకు ముందే తెలుసు." మేము చివరికి మరొక తయారీదారు నుండి కొత్త గేట్‌వేని కొనుగోలు చేయడం ద్వారా సమస్యను పరిష్కరించాము (మాజీ రక్షణలో, FORTRAN ప్రోగ్రామ్‌లను బదిలీ చేయలేకపోవడం కొందరికి ప్రయోజనం కావచ్చు!).
హార్డ్ టైమ్స్
కొన్ని సంవత్సరాల క్రితం, ఫేజ్ 40 క్లినికల్ ట్రయల్స్ ఖర్చులను తగ్గించడానికి పెర్ల్‌లో ETL సిస్టమ్‌ను రూపొందించడంలో పని చేస్తున్నప్పుడు, నేను దాదాపు 000 తేదీలను ప్రాసెస్ చేయాల్సి వచ్చింది. వారిలో ఇద్దరు పరీక్షలో ఉత్తీర్ణత సాధించలేదు. ఈ తేదీలు క్లయింట్ అందించిన డేటా నుండి తీసుకోబడినందున ఇది నాకు పెద్దగా ఇబ్బంది కలిగించలేదు, ఇది చాలా ఆశ్చర్యకరంగా ఉంటుంది. కానీ నేను అసలు డేటాను తనిఖీ చేసినప్పుడు, ఈ తేదీలు జనవరి 1, 2011 మరియు జనవరి 1, 2007 అని తేలింది. నేను ఇప్పుడే వ్రాసిన ప్రోగ్రామ్‌లో బగ్ ఉందని నేను అనుకున్నాను, కానీ అప్పటికే 30 సంవత్సరాలు అని తేలింది. పాతది. సాఫ్ట్‌వేర్ పర్యావరణ వ్యవస్థ గురించి తెలియని వారికి ఇది రహస్యంగా అనిపించవచ్చు. డబ్బు సంపాదించాలనే మరో కంపెనీ దీర్ఘకాల నిర్ణయం కారణంగా, ఒక కంపెనీ అనుకోకుండా మరియు మరొకటి ఉద్దేశపూర్వకంగా ప్రవేశపెట్టిన బగ్‌ను పరిష్కరించడానికి నా క్లయింట్ నాకు చెల్లించాడు. నేను ఏమి మాట్లాడుతున్నానో మీరు అర్థం చేసుకోవడానికి, నేను బగ్‌గా మారిన ఫీచర్‌ని జోడించిన కంపెనీ గురించి, అలాగే నేను పరిష్కరించిన మిస్టీరియస్ బగ్‌కు దోహదపడిన మరికొన్ని ఆసక్తికరమైన సంఘటనల గురించి మాట్లాడాలి.
మంచి పాత రోజుల్లో, Apple కంప్యూటర్లు కొన్నిసార్లు ఆకస్మికంగా తమ తేదీని జనవరి 1, 1904కి రీసెట్ చేస్తాయి. కారణం చాలా సులభం: ఇది తేదీ మరియు సమయాన్ని ట్రాక్ చేయడానికి బ్యాటరీతో నడిచే “సిస్టమ్ క్లాక్”ని ఉపయోగించింది. బ్యాటరీ చనిపోయినప్పుడు ఏమి జరిగింది? కంప్యూటర్లు ఒక యుగం ప్రారంభం నుండి తేదీని సెకన్ల సంఖ్య ద్వారా ట్రాక్ చేయడం ప్రారంభించాయి. యుగం ద్వారా మేము సూచన అసలు తేదీని ఉద్దేశించాము మరియు Macintoshes కోసం ఇది జనవరి 1, 1904. మరియు బ్యాటరీ చనిపోయిన తర్వాత, ప్రస్తుత తేదీ పేర్కొన్న తేదీకి రీసెట్ చేయబడింది. అయితే ఇది ఎందుకు జరిగింది?
ఇంతకుముందు, Apple అసలు తేదీ నుండి సెకన్ల సంఖ్యను నిల్వ చేయడానికి 32 బిట్‌లను ఉపయోగించింది. ఒక బిట్ రెండు విలువలలో ఒకదాన్ని నిల్వ చేయగలదు - 1 లేదా 0. రెండు బిట్‌లు నాలుగు విలువలలో ఒకదాన్ని నిల్వ చేయగలవు: 00, 01, 10, 11. మూడు బిట్‌లు - ఎనిమిదిలో ఒక విలువ: 000, 001, 010, 011, 100 , 101, 110, 111, మొదలైనవి. మరియు 32 232 విలువలలో ఒకదాన్ని నిల్వ చేయగలదు, అంటే 4 సెకన్లు. Apple తేదీల కోసం, ఇది దాదాపు 294 సంవత్సరాలకు సమానం, కాబట్టి పాత Macలు 967 తర్వాత తేదీలను నిర్వహించలేవు. మరియు సిస్టమ్ బ్యాటరీ చనిపోతే, యుగం ప్రారంభం నుండి తేదీ 296 సెకన్లకు రీసెట్ చేయబడుతుంది మరియు మీరు కంప్యూటర్‌ను ఆన్ చేసిన ప్రతిసారీ (లేదా మీరు కొత్త బ్యాటరీని కొనుగోలు చేసే వరకు) తేదీని మాన్యువల్‌గా సెట్ చేయాలి.
ఏది ఏమైనప్పటికీ, యుగం నుండి తేదీలను సెకన్లుగా నిల్వ చేయాలనే Apple యొక్క నిర్ణయం యొక్క అర్థం, మేము యుగానికి ముందు తేదీలను నిర్వహించలేకపోయాము, ఇది చాలా విస్తృతమైన పరిణామాలను కలిగి ఉంది, మనం చూస్తాము. ఆపిల్ ఒక ఫీచర్‌ను ప్రవేశపెట్టింది, బగ్ కాదు. ఇతర విషయాలతోపాటు, దీని అర్థం Macintosh ఆపరేటింగ్ సిస్టమ్ "మిలీనియం బగ్" (పరిమితులను అధిగమించడానికి వారి స్వంత తేదీ వ్యవస్థలను కలిగి ఉన్న అనేక Mac అప్లికేషన్‌ల గురించి చెప్పలేము) నుండి రోగనిరోధక శక్తిని కలిగి ఉంది.
ముందుకి వెళ్ళు. మేము లోటస్ 1-2-3, IBM యొక్క "కిల్లర్ అప్లికేషన్"ని ఉపయోగించాము, ఇది PC విప్లవాన్ని ప్రారంభించడంలో సహాయపడింది, అయినప్పటికీ Apple కంప్యూటర్లలో VisiCalc ఉంది, ఇది వ్యక్తిగత కంప్యూటర్‌ను విజయవంతం చేసింది. న్యాయంగా, 1-2-3 కనిపించకపోతే, PC లు అరుదుగా టేకాఫ్ చేయబడవు మరియు వ్యక్తిగత కంప్యూటర్ల చరిత్ర చాలా భిన్నంగా అభివృద్ధి చెందుతుంది. లోటస్ 1-2-3 1900ని లీప్ ఇయర్‌గా తప్పుగా పరిగణించింది. మైక్రోసాఫ్ట్ తన మొదటి స్ప్రెడ్‌షీట్ మల్టీప్లాన్‌ను విడుదల చేసినప్పుడు, అది మార్కెట్‌లో చిన్న వాటాను స్వాధీనం చేసుకుంది. మరియు వారు ఎక్సెల్ ప్రాజెక్ట్‌ను ప్రారంభించినప్పుడు, వారు లోటస్ 1-2-3 నుండి వరుస మరియు కాలమ్ నామకరణ పథకాన్ని కాపీ చేయడమే కాకుండా, 1900ని లీప్ ఇయర్‌గా ఉద్దేశపూర్వకంగా పరిగణించడం ద్వారా బగ్ అనుకూలతను నిర్ధారించాలని నిర్ణయించుకున్నారు. ఈ సమస్య నేటికీ ఉంది. అంటే, 1-2-3లో ఇది ఒక బగ్, కానీ ఎక్సెల్‌లో ఇది 1-2-3 వినియోగదారులందరూ తప్పుగా ఉన్నప్పటికీ, డేటాను మార్చకుండా ఎక్సెల్‌లోకి తమ టేబుల్‌లను దిగుమతి చేసుకోవచ్చని నిర్ధారించే ఒక చేతన నిర్ణయం.
అయితే మరో సమస్య వచ్చింది. మొదట, మైక్రోసాఫ్ట్ Macintosh కోసం ఎక్సెల్‌ని విడుదల చేసింది, ఇది జనవరి 1, 1904కి ముందు తేదీలను గుర్తించలేదు. మరియు ఎక్సెల్‌లో, జనవరి 1, 1900 శకానికి నాందిగా పరిగణించబడింది. అందువల్ల, డెవలపర్‌లు ఒక మార్పు చేసారు, తద్వారా వారి ప్రోగ్రామ్ యుగం యొక్క రకాన్ని గుర్తించింది మరియు కావలసిన యుగానికి అనుగుణంగా దానిలో డేటాను నిల్వ చేస్తుంది. మైక్రోసాఫ్ట్ దీని గురించి వివరణాత్మక కథనాన్ని కూడా రాసింది. మరియు ఈ నిర్ణయం నా బగ్‌కు దారితీసింది.
నా ETL సిస్టమ్ Windowsలో సృష్టించబడిన వినియోగదారుల నుండి Excel స్ప్రెడ్‌షీట్‌లను పొందింది, కానీ Macలో కూడా సృష్టించబడుతుంది. కాబట్టి, పట్టికలో యుగం ప్రారంభం జనవరి 1, 1900 లేదా జనవరి 1, 1904 కావచ్చు. ఎలా కనుక్కోవాలి? Excel ఫైల్ ఫార్మాట్ అవసరమైన సమాచారాన్ని చూపుతుంది, కానీ నేను ఉపయోగించిన పార్సర్ దానిని చూపించలేదు (ఇప్పుడు అది చూపుతుంది), మరియు నిర్దిష్ట పట్టిక కోసం యుగం మీకు తెలుసని భావించాను. నేను బహుశా ఎక్సెల్ బైనరీ ఆకృతిని అర్థం చేసుకోవడానికి మరియు పార్సర్ రచయితకు ప్యాచ్‌ని పంపడానికి ఎక్కువ సమయం వెచ్చించి ఉండవచ్చు, కానీ క్లయింట్ కోసం నేను చాలా ఎక్కువ చేయాల్సి ఉంది, కాబట్టి నేను యుగాన్ని నిర్ణయించడానికి త్వరగా ఒక హ్యూరిస్టిక్‌ను వ్రాసాను. ఆమె సింపుల్‌గా ఉండేది.
Excelలో, జూలై 5, 1998 తేదీని "07-05-98" (పనికిరాని అమెరికన్ సిస్టమ్), "జులై 5, 98", "జూలై 5, 1998", "5-జూలై-98" లేదా కొన్ని ఇతర ఫార్మాట్. మరొక పనికిరాని ఫార్మాట్ (హాస్యాస్పదంగా, Excel యొక్క నా వెర్షన్ అందించని ఫార్మాట్లలో ఒకటి ISO 8601). అయితే, పట్టికలో, ఆకృతీకరించని తేదీ యుగం-35981 కోసం "1900" లేదా యుగం-34519 కోసం "1904"గా నిల్వ చేయబడింది (సంఖ్యలు యుగం నుండి ఎన్ని రోజులను సూచిస్తాయి). నేను ఆకృతీకరించిన తేదీ నుండి సంవత్సరాన్ని సంగ్రహించడానికి సాధారణ పార్సర్‌ని ఉపయోగించాను, ఆపై ఆకృతీకరించని తేదీ నుండి సంవత్సరాన్ని సంగ్రహించడానికి Excel పార్సర్‌ని ఉపయోగించాను. రెండు విలువలు 4 సంవత్సరాలు భిన్నంగా ఉంటే, నేను ఎపోచ్-1904తో సిస్టమ్‌ని ఉపయోగిస్తున్నానని నాకు తెలుసు.
నేను ఫార్మాట్ చేసిన తేదీలను ఎందుకు ఉపయోగించలేదు? ఎందుకంటే కోల్పోయిన నెల రోజుతో జూలై 5, 1998ని "జూలై, 98"గా ఫార్మాట్ చేయవచ్చు. మేము వాటిని చాలా విభిన్న మార్గాల్లో సృష్టించిన చాలా కంపెనీల నుండి పట్టికలను అందుకున్నాము, తేదీలను గుర్తించడం మా ఇష్టం (ఈ సందర్భంలో, నేను). అదనంగా, ఎక్సెల్ సరైనది అయితే, మనం కూడా అలా చేయాలి!
అదే సమయంలో నేను 39082ని ఎదుర్కొన్నాను. లోటస్ 1-2-3 1900ని లీప్ ఇయర్‌గా పరిగణించిందని మరియు ఇది ఎక్సెల్‌లో నమ్మకంగా పునరావృతమైందని నేను మీకు గుర్తు చేస్తాను. మరియు ఇది 1900 సంవత్సరానికి ఒక రోజుని జోడించినందున, చాలా తేదీ గణన విధులు ఆ రోజు తప్పు కావచ్చు. అంటే, 39082 జనవరి 1, 2011 (Macsలో) లేదా డిసెంబర్ 31, 2006 (Windowsలో) అయి ఉండవచ్చు. నా “సంవత్సరం పార్సర్” 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ల ప్రారంభంలో, మా నాన్న స్టోరేజ్ టెక్నాలజీలో పనిచేశారు, ఇది ఇప్పుడు పనిచేయని విభాగం, ఇది హై-స్పీడ్ టేప్ ఫీడింగ్ కోసం టేప్ డ్రైవ్‌లు మరియు వాయు వ్యవస్థలను సృష్టించింది.
వారు ఏడు "B" డ్రైవ్‌లకు కనెక్ట్ చేయబడిన ఒక సెంట్రల్ "A" డ్రైవ్‌ను కలిగి ఉండేలా డ్రైవ్‌లను పునఃరూపకల్పన చేసారు మరియు "A" డ్రైవ్‌ను నియంత్రించే RAMలోని చిన్న OS అన్ని "B" డ్రైవ్‌లకు రీడ్ మరియు రైట్ ఆపరేషన్‌లను అప్పగించగలదు.
"A" డ్రైవ్ ప్రారంభించబడిన ప్రతిసారి, ఆపరేటింగ్ సిస్టమ్‌ను దాని మెమరీలోకి లోడ్ చేయడానికి "A"కి కనెక్ట్ చేయబడిన పరిధీయ డ్రైవ్‌లో ఫ్లాపీ డిస్క్‌ను చొప్పించడం అవసరం. ఇది చాలా ప్రాచీనమైనది: కంప్యూటింగ్ శక్తి 8-బిట్ మైక్రోకంట్రోలర్ ద్వారా అందించబడింది.
అటువంటి పరికరాల కోసం లక్ష్య ప్రేక్షకులు చాలా పెద్ద డేటా గిడ్డంగులు కలిగిన కంపెనీలు - బ్యాంకులు, రిటైల్ చైన్లు మొదలైనవి - చాలా చిరునామా లేబుల్‌లు లేదా బ్యాంక్ స్టేట్‌మెంట్‌లను ముద్రించాల్సిన అవసరం ఉంది.
ఒక క్లయింట్‌కి సమస్య ఉంది. ప్రింట్ జాబ్ మధ్యలో, ఒక నిర్దిష్ట డ్రైవ్ "A" పని చేయడం ఆగిపోతుంది, దీని వలన మొత్తం జాబ్ నిలిచిపోతుంది. డ్రైవ్ యొక్క ఆపరేషన్‌ను పునరుద్ధరించడానికి, సిబ్బంది ప్రతిదీ రీబూట్ చేయాల్సి ఉంటుంది. మరియు ఇది ఆరు గంటల పని మధ్యలో జరిగితే, అప్పుడు భారీ మొత్తంలో ఖరీదైన కంప్యూటర్ సమయం పోతుంది మరియు మొత్తం ఆపరేషన్ యొక్క షెడ్యూల్ చెదిరిపోతుంది.
స్టోరేజ్ టెక్నాలజీస్ నుంచి సాంకేతిక నిపుణులను పంపారు. కానీ వారి ఉత్తమ ప్రయత్నాలు ఉన్నప్పటికీ, వారు పరీక్ష పరిస్థితుల్లో బగ్‌ను పునరుత్పత్తి చేయలేకపోయారు: ఇది పెద్ద ముద్రణ ఉద్యోగాల మధ్యలో జరిగినట్లు అనిపించింది. సమస్య హార్డ్‌వేర్ కాదు, వారు చేయగలిగిన ప్రతిదాన్ని భర్తీ చేశారు: RAM, మైక్రోకంట్రోలర్, ఫ్లాపీ డ్రైవ్, టేప్ డ్రైవ్‌లోని ప్రతి ఊహించదగిన భాగం - సమస్య కొనసాగింది.
తర్వాత టెక్నీషియన్లు హెడ్‌క్వార్టర్స్‌కి ఫోన్ చేసి ఎక్స్‌పర్ట్‌ని పిలిచారు.
నిపుణుడు ఒక కుర్చీ మరియు ఒక కప్పు కాఫీ పట్టుకుని, కంప్యూటర్ గదిలో కూర్చున్నాడు-ఆ రోజుల్లో కంప్యూటర్‌లకు అంకితమైన గదులు ఉన్నాయి-మరియు సిబ్బంది పెద్ద ప్రింట్ జాబ్‌ను క్యూలో ఉంచడాన్ని చూశారు. నిపుణుడు వైఫల్యం కోసం వేచి ఉన్నాడు - మరియు అది జరిగింది. అందరూ నిపుణుడి వైపు చూశారు, కానీ ఇది ఎందుకు జరిగిందో అతనికి తెలియదు. కాబట్టి అతను పనిని మళ్లీ క్యూలో ఉంచమని ఆదేశించాడు మరియు సిబ్బంది మరియు సాంకేతిక నిపుణులు అందరూ పనికి తిరిగి వచ్చారు.
నిపుణుడు మళ్ళీ కుర్చీలో కూర్చుని వైఫల్యం కోసం వేచి ఉండటం ప్రారంభించాడు. దాదాపు ఆరు గంటలు గడిచినా వైఫల్యం సంభవించింది. నిపుణుడికి మళ్లీ ఆలోచనలు లేవు, అంతా మనుషులతో నిండిన గదిలోనే జరిగింది తప్ప. అతను మిషన్‌ను పునఃప్రారంభించమని ఆదేశించాడు, తిరిగి కూర్చుని వేచి ఉన్నాడు.
మూడవ వైఫల్యం ద్వారా, నిపుణుడు ఏదో గమనించాడు. విదేశీ డ్రైవ్‌లో సిబ్బంది టేపులను మార్చినప్పుడు వైఫల్యం సంభవించింది. అంతేకాకుండా, ఉద్యోగులలో ఒకరు నేలపై ఒక నిర్దిష్ట టైల్ ద్వారా నడిచిన వెంటనే వైఫల్యం సంభవించింది.
6 నుంచి 8 అంగుళాల ఎత్తులో వేసిన అల్యూమినియం టైల్స్‌తో ఎత్తైన నేలను తయారు చేశారు. ఒక ముఖ్యమైన కేబుల్‌పై ప్రమాదవశాత్తూ ఎవరూ అడుగు పెట్టకుండా నిరోధించడానికి కంప్యూటర్ల నుండి అనేక వైర్లు ఎత్తైన నేల కిందకు పరిగెత్తాయి. ఎత్తైన నేల కింద చెత్తాచెదారం రాకుండా టైల్స్ చాలా గట్టిగా వేయబడ్డాయి.
పలకలలో ఒకటి వైకల్యంతో ఉందని నిపుణుడు గ్రహించాడు. ఒక ఉద్యోగి దాని మూలలో అడుగు పెట్టినప్పుడు, టైల్ అంచులు ప్రక్కనే ఉన్న పలకలకు వ్యతిరేకంగా రుద్దుతారు. పలకలను కనెక్ట్ చేసిన ప్లాస్టిక్ భాగాలు కూడా వాటితో రుద్దుతారు, ఇది రేడియో ఫ్రీక్వెన్సీ జోక్యాన్ని సృష్టించే స్టాటిక్ మైక్రోడిశ్చార్జెస్‌కు కారణమైంది.
నేడు, రేడియో ఫ్రీక్వెన్సీ జోక్యం నుండి RAM మెరుగ్గా రక్షించబడింది. కానీ ఇన్నేళ్లలో అలా జరగలేదు. ఈ జోక్యం మెమరీకి అంతరాయం కలిగించిందని మరియు దానితో ఆపరేటింగ్ సిస్టమ్ యొక్క ఆపరేషన్ అని నిపుణుడు గ్రహించాడు. అతను మద్దతు సేవను పిలిచాడు, కొత్త పలకలను ఆదేశించాడు, వాటిని స్వయంగా ఇన్స్టాల్ చేసాడు మరియు సమస్య అదృశ్యమైంది.
ఇది అధిక ఆటుపోట్లు!
కథ పోర్ట్స్‌మౌత్‌లోని కార్యాలయం యొక్క నాల్గవ లేదా ఐదవ అంతస్తులో ఉన్న సర్వర్ గదిలో (నేను అనుకుంటున్నాను) డాక్స్ ప్రాంతంలో జరిగింది.
ఒకరోజు మెయిన్ డేటాబేస్ ఉన్న Unix సర్వర్ క్రాష్ అయింది. వారు అతనిని రీబూట్ చేసారు, కానీ అతను సంతోషంగా పదే పదే పడుతూనే ఉన్నాడు. మేము మద్దతు సేవ నుండి ఎవరికైనా కాల్ చేయాలని నిర్ణయించుకున్నాము.
సపోర్టు చేసే వ్యక్తి... అతని పేరు మార్క్ అని నేను అనుకుంటున్నాను, కానీ అది పర్వాలేదు.. అతను నాకు తెలుసునని నేను అనుకోను. ఇది పట్టింపు లేదు, నిజంగా. మార్క్‌తో కట్టుబడి ఉందాం, సరేనా? గొప్ప.
కాబట్టి, కొన్ని గంటల తర్వాత మార్క్ వచ్చాడు (ఇది లీడ్స్ నుండి పోర్ట్స్‌మౌత్‌కు చాలా దూరం కాదు, మీకు తెలుసా), సర్వర్‌ను ఆన్ చేసింది మరియు ప్రతిదీ సమస్యలు లేకుండా పనిచేసింది. సాధారణ తిట్టు మద్దతు, క్లయింట్ దీని గురించి చాలా కలత చెందుతుంది. మార్క్ లాగ్ ఫైల్‌లను చూస్తాడు మరియు అవాంఛనీయంగా ఏమీ కనుగొనలేదు. కాబట్టి మార్క్ రైలులో తిరిగి వస్తాడు (లేదా అతను వచ్చిన రవాణా విధానం ఏదైనా, అది నాకు తెలిసినంత వరకు అది కుంటి ఆవు అయి ఉండవచ్చు... ఏమైనప్పటికీ, పర్వాలేదు, సరేనా?) మరియు లీడ్స్‌కు తిరిగి వెళ్తాడు, వృధాగా రోజు.
అదే రోజు సాయంత్రం సర్వర్ మళ్లీ క్రాష్ అవుతుంది. అదే కథ... సర్వర్ ఎక్కదు. మార్క్ రిమోట్‌గా సహాయం చేయడానికి ప్రయత్నిస్తాడు, కానీ క్లయింట్ సర్వర్‌ను ప్రారంభించలేరు.
మరొక రైలు, బస్సు, నిమ్మకాయ లేదా ఇతర చెత్త, మరియు మార్క్ పోర్ట్స్‌మౌత్‌కు తిరిగి వచ్చాడు. చూడండి, ఎటువంటి సమస్యలు లేకుండా సర్వర్ బూట్ అవుతుంది! అద్భుతం. మార్క్ చాలా గంటలు ఆపరేటింగ్ సిస్టమ్ లేదా సాఫ్ట్‌వేర్‌తో ప్రతిదీ సరిగ్గా ఉందో లేదో తనిఖీ చేస్తూ లీడ్స్‌కు బయలుదేరాడు.
రోజు మధ్యలో సర్వర్ క్రాష్ అవుతుంది (సులభంగా తీసుకోండి!). ఈసారి సర్వర్‌ను భర్తీ చేయడానికి హార్డ్‌వేర్ మద్దతు వ్యక్తులను తీసుకురావడం సహేతుకమైనదిగా కనిపిస్తోంది. కానీ లేదు, సుమారు 10 గంటల తర్వాత అది కూడా వస్తుంది.
చాలా రోజుల పాటు పరిస్థితి పునరావృతమైంది. సర్వర్ పని చేస్తుంది, సుమారు 10 గంటల తర్వాత క్రాష్ అవుతుంది మరియు తదుపరి 2 గంటల వరకు ప్రారంభం కాదు. వారు శీతలీకరణ, మెమరీ లీక్‌లను తనిఖీ చేసారు, వారు ప్రతిదీ తనిఖీ చేసారు, కానీ ఏమీ కనుగొనబడలేదు. అప్పుడు క్రాష్‌లు ఆగిపోయాయి.
వారం రోజులు నిరాటంకంగా గడిచిపోయాయి... అందరూ సంతోషంగా ఉన్నారు. అంతా మళ్లీ మొదలయ్యే వరకు సంతోషంగా ఉండండి. చిత్రం అదే. 10 గంటల పని, 2-3 గంటల పనికిరాని సమయం...
ఆపై ఎవరో (ఈ వ్యక్తికి ITతో సంబంధం లేదని వారు నాకు చెప్పారని నేను అనుకుంటున్నాను) ఇలా అన్నారు:
"ఇది పోటు!"
ఆశ్చర్యార్థకం ఖాళీ చూపులతో ఎదురైంది మరియు సెక్యూరిటీ కాల్ బటన్ వద్ద ఎవరైనా చేయి సంకోచించవచ్చు.
"ఇది ఆటుపోట్లతో పనిచేయడం ఆపివేస్తుంది."
కాఫీ కోసం కూర్చున్నప్పుడు టైడ్ ఇయర్‌బుక్‌ను చదవడానికి అవకాశం లేని IT మద్దతు కార్మికులకు ఇది పూర్తిగా విదేశీ భావనగా కనిపిస్తుంది. వారం రోజులుగా సర్వర్ ఫెయిల్యూర్‌లు లేకుండా పని చేస్తున్నందున దీనికి పోటుకు ఎలాంటి సంబంధం లేదని వివరించారు.
"గత వారం పోటు తక్కువగా ఉంది, కానీ ఈ వారం అది ఎక్కువగా ఉంది."
యాచ్ లైసెన్స్ లేని వారి కోసం ఒక చిన్న పదజాలం. ఆటుపోట్లు చంద్ర చక్రంపై ఆధారపడి ఉంటాయి. మరియు భూమి తిరుగుతున్నప్పుడు, ప్రతి 12,5 గంటలకు సూర్యుడు మరియు చంద్రుని యొక్క గురుత్వాకర్షణ పుల్ టైడల్ వేవ్‌ను సృష్టిస్తుంది. 12,5 గంటల చక్రం ప్రారంభంలో అధిక ఆటుపోట్లు, చక్రం మధ్యలో ఒక ఎబ్బ్ మరియు చివరిలో మళ్లీ అధిక అలలు ఉన్నాయి. కానీ చంద్రుని కక్ష్య మారుతున్న కొద్దీ, అల్ప మరియు అధిక పోటు మధ్య వ్యత్యాసం కూడా మారుతుంది. చంద్రుడు సూర్యుడు మరియు భూమికి మధ్య లేదా భూమికి ఎదురుగా ఉన్నప్పుడు (పూర్తి చంద్రుడు లేదా చంద్రుడు కాదు), మనకు సిజిజిన్ అలలు వస్తాయి - అత్యధిక ఆటుపోట్లు మరియు అత్యల్ప తక్కువ అలలు. అర్ధ చంద్రుని వద్ద మనకు చతుర్భుజ అలలు లభిస్తాయి - అత్యల్ప అలలు. రెండు తీవ్రతల మధ్య వ్యత్యాసం బాగా తగ్గుతుంది. చంద్ర చక్రం 28 రోజులు ఉంటుంది: సిజిజియన్ - క్వాడ్రేచర్ - సిజిజియన్ - క్వాడ్రేచర్.
టెక్నీషియన్లకు టైడల్ దళాల సారాంశాన్ని వివరించినప్పుడు, వారు వెంటనే పోలీసులను పిలవాలని భావించారు. మరియు చాలా తార్కికం. కానీ వాసి సరైనదేనని తేలింది. రెండు వారాల ముందు, ఒక డిస్ట్రాయర్ కార్యాలయం నుండి చాలా దూరంలో ఉంది. ఆటుపోట్లు ఒక నిర్దిష్ట ఎత్తుకు పెంచిన ప్రతిసారీ, ఓడ యొక్క రాడార్ పోస్ట్ సర్వర్ గది అంతస్తులో ముగుస్తుంది. మరియు రాడార్ (లేదా ఎలక్ట్రానిక్ వార్ఫేర్ పరికరాలు లేదా కొన్ని ఇతర సైనిక బొమ్మలు) కంప్యూటర్లలో గందరగోళాన్ని సృష్టించాయి.
రాకెట్ కోసం ఫ్లైట్ మిషన్
ఆపరేటింగ్ సిస్టమ్, కంపైలర్ మరియు భాష యొక్క కొత్త వెర్షన్‌లకు పెద్ద (సుమారు 400 వేల లైన్లు) రాకెట్ లాంచ్ కంట్రోల్ మరియు మానిటరింగ్ సిస్టమ్‌ను పోర్ట్ చేయడం నాకు అప్పగించబడింది. మరింత ఖచ్చితంగా చెప్పాలంటే, సోలారిస్ 2.5.1 నుండి సోలారిస్ 7 వరకు మరియు అడా 83లో వ్రాయబడిన వెర్డిక్స్ అడా డెవలప్‌మెంట్ సిస్టమ్ (VADS) నుండి అడా 95లో వ్రాయబడిన రేషనల్ అపెక్స్ అడా సిస్టమ్ వరకు. VADSని రేషనల్ కొనుగోలు చేసింది మరియు దాని ఉత్పత్తి వాడుకలో లేదు, అయినప్పటికీ అపెక్స్ కంపైలర్‌కు మార్పును సులభతరం చేయడానికి VADS-నిర్దిష్ట ప్యాకేజీల అనుకూల సంస్కరణలను అమలు చేయడానికి రేషనల్ ప్రయత్నించింది.
కోడ్‌ను క్లీన్‌గా కంపైల్ చేయడంలో ముగ్గురు వ్యక్తులు నాకు సహాయం చేసారు. రెండు వారాలు పట్టింది. ఆపై సిస్టమ్ పని చేయడానికి నేను నా స్వంతంగా పనిచేశాను. సంక్షిప్తంగా, ఇది నేను ఎదుర్కొన్న సాఫ్ట్‌వేర్ సిస్టమ్ యొక్క చెత్త నిర్మాణం మరియు అమలు, కాబట్టి పోర్ట్ పూర్తి చేయడానికి మరో రెండు నెలలు పట్టింది. సిస్టమ్ పరీక్ష కోసం సమర్పించబడింది, దీనికి మరికొన్ని నెలలు పట్టింది. పరీక్ష సమయంలో కనుగొనబడిన బగ్‌లను నేను వెంటనే సరిదిద్దాను, కాని వాటి సంఖ్య త్వరగా తగ్గింది (సోర్స్ కోడ్ ఉత్పత్తి వ్యవస్థ, కాబట్టి దాని కార్యాచరణ చాలా విశ్వసనీయంగా పనిచేసింది, కొత్త కంపైలర్‌కు అనుసరణ సమయంలో తలెత్తిన బగ్‌లను నేను తొలగించాల్సి వచ్చింది). ఆఖరికి, అన్నీ అనుకున్నట్టు పని చేస్తున్నప్పుడు, నేను వేరే ప్రాజెక్ట్‌కి బదిలీ అయ్యాను.
మరియు థాంక్స్ గివింగ్ ముందు శుక్రవారం, ఫోన్ మోగింది.
రాకెట్ ప్రయోగాన్ని సుమారు మూడు వారాల్లో పరీక్షించాల్సి ఉంది మరియు కౌంట్‌డౌన్ యొక్క ప్రయోగశాల పరీక్షల సమయంలో, ఆదేశాల క్రమం నిరోధించబడింది. నిజ జీవితంలో, ఇది పరీక్షను నిలిపివేస్తుంది మరియు ఇంజిన్‌ను ప్రారంభించిన కొద్ది సెకన్లలో అడ్డంకి ఏర్పడినట్లయితే, సహాయక వ్యవస్థలలో అనేక కోలుకోలేని చర్యలు సంభవిస్తాయి, దీనికి రాకెట్ యొక్క సుదీర్ఘమైన మరియు ఖరీదైన-సంసిద్ధత అవసరం. ఇది ప్రారంభం కాదు, కానీ చాలా మంది సమయం మరియు చాలా డబ్బు నష్టం గురించి చాలా కలత చెందారు. డిపార్ట్‌మెంట్ ఆఫ్ డిఫెన్స్ డబ్బును నిర్లక్ష్యంగా ఖర్చు చేస్తుందని ఎవరూ మీకు చెప్పనివ్వవద్దు—నేను బడ్జెట్‌ను మొదటి లేదా రెండో షెడ్యూల్‌ని అనుసరించని కాంట్రాక్టు మేనేజర్‌ని ఎప్పుడూ కలవలేదు.
మునుపటి నెలల్లో, ఈ కౌంట్‌డౌన్ ఛాలెంజ్ అనేక వైవిధ్యాలలో వందల సార్లు అమలు చేయబడింది, కొన్ని చిన్న ఎక్కిళ్ళు మాత్రమే ఉన్నాయి. కాబట్టి ఇది సంభవించే సంభావ్యత చాలా తక్కువగా ఉంది, కానీ దాని పరిణామాలు చాలా ముఖ్యమైనవి. ఈ రెండు కారకాలను గుణించండి మరియు నాకు మరియు డజన్ల కొద్దీ ఇంజనీర్లు మరియు మేనేజర్‌ల కోసం ఈ వార్త శిధిలమైన సెలవు వారాన్ని అంచనా వేసిందని మీరు అర్థం చేసుకుంటారు.
మరియు సిస్టమ్‌ను పోర్ట్ చేసిన వ్యక్తిగా నాపై శ్రద్ధ పెట్టారు.
చాలా సెక్యూరిటీ-క్రిటికల్ సిస్టమ్‌ల మాదిరిగానే, చాలా పారామీటర్‌లు లాగ్ చేయబడ్డాయి, కాబట్టి సిస్టమ్ క్రాష్ అయ్యే ముందు అమలు చేయబడిన కొన్ని కోడ్ లైన్‌లను గుర్తించడం చాలా సులభం. మరియు వాస్తవానికి, వాటి గురించి అసాధారణంగా ఏమీ లేదు; అదే వ్యక్తీకరణలు ఒకే రన్‌లో అక్షరాలా వేలసార్లు విజయవంతంగా అమలు చేయబడ్డాయి.
కంపైలర్‌ని డెవలప్ చేసిన వారు మరియు వారు డెవలప్ చేసిన కొన్ని రొటీన్‌లను అనుమానాస్పద కోడ్‌లో పిలిచినందున మేము అపెక్స్‌లోని వ్యక్తులను హేతుబద్ధంగా పిలిచాము. వారు (మరియు ప్రతి ఒక్కరూ) అక్షరాలా జాతీయ ప్రాముఖ్యత కలిగిన సమస్య యొక్క మూలాన్ని పొందవలసిన అవసరం ఉందని ఆకట్టుకున్నారు.
పత్రికలలో ఆసక్తికరమైన ఏమీ లేనందున, మేము స్థానిక ప్రయోగశాలలో సమస్యను పునరుత్పత్తి చేయడానికి ప్రయత్నించాలని నిర్ణయించుకున్నాము. ఈవెంట్ 1000 పరుగులకు ఒకసారి జరిగినందున ఇది అంత తేలికైన పని కాదు. ఒక అనుమానిత కారణం ఏమిటంటే విక్రేత-అభివృద్ధి చేసిన మ్యూటెక్స్ ఫంక్షన్‌కి కాల్ (VADS మైగ్రేషన్ ప్యాకేజీలో భాగం) Unlock అన్‌లాక్ చేయడానికి దారితీయలేదు. ఫంక్షన్ అని పిలిచే ప్రాసెసింగ్ థ్రెడ్ హృదయ స్పందన సందేశాలను ప్రాసెస్ చేసింది, ఇది నామమాత్రంగా ప్రతి సెకనుకు వస్తుంది. మేము ఫ్రీక్వెన్సీని 10 Hzకి పెంచాము, అంటే సెకనుకు 10 సార్లు, మరియు అమలు చేయడం ప్రారంభించాము. దాదాపు గంట తర్వాత సిస్టమ్ స్వయంగా లాక్ చేయబడింది. లాగ్‌లో, రికార్డ్ చేయబడిన సందేశాల క్రమం విఫలమైన పరీక్ష సమయంలో మాదిరిగానే ఉందని మేము చూశాము. మేము ఇంకా అనేక పరుగులు చేసాము, సిస్టమ్ ప్రారంభమైన 45-90 నిమిషాల తర్వాత స్థిరంగా బ్లాక్ చేయబడింది మరియు ప్రతిసారీ లాగ్ అదే మార్గాన్ని కలిగి ఉంటుంది. మేము సాంకేతికంగా వేర్వేరు కోడ్‌లను అమలు చేస్తున్నప్పటికీ - సందేశ ఫ్రీక్వెన్సీ భిన్నంగా ఉంది - సిస్టమ్ యొక్క ప్రవర్తన ఒకేలా ఉంది, కాబట్టి ఈ లోడ్ దృశ్యం అదే సమస్యను కలిగిస్తుందని మేము విశ్వసించాము.
వ్యక్తీకరణల క్రమంలో సరిగ్గా ఎక్కడ నిరోధించబడిందో ఇప్పుడు మనం గుర్తించాల్సిన అవసరం ఉంది.
సిస్టమ్ యొక్క ఈ అమలు అడా టాస్క్ సిస్టమ్‌ను ఉపయోగించింది మరియు దానిని చాలా పేలవంగా ఉపయోగించింది. టాస్క్‌లు అనేది అడాలో ఉన్నత-స్థాయి ఏకకాలంలో అమలు చేయగల నిర్మాణం, అమలు యొక్క థ్రెడ్‌ల వంటిది, భాషలోనే నిర్మించబడింది. రెండు పనులు కమ్యూనికేట్ చేయవలసి వచ్చినప్పుడు, వారు "రెండెజౌస్‌ను సెట్ చేస్తారు", అవసరమైన డేటాను మార్పిడి చేస్తారు, ఆపై రెండెజౌస్‌ను ఆపివేసి, వారి స్వతంత్ర అమలుకు తిరిగి వస్తారు. అయితే, వ్యవస్థ భిన్నంగా అమలు చేయబడింది. టార్గెట్ టాస్క్ రెండెజౌస్ అయిన తర్వాత, ఆ టార్గెట్ టాస్క్ మరొక టాస్క్‌తో రెండెజ్‌వౌజ్ చేయబడింది, అది మూడవ టాస్క్‌తో రెండెజ్‌వౌజ్ చేయబడింది మరియు కొంత ప్రాసెసింగ్ పూర్తయ్యే వరకు. దీని తరువాత, ఈ సమావేశాలు అన్నీ పూర్తయ్యాయి మరియు ప్రతి పని దాని అమలుకు తిరిగి రావాలి. అంటే, మేము ప్రపంచంలోనే అత్యంత ఖరీదైన ఫంక్షన్ కాల్ సిస్టమ్‌తో వ్యవహరిస్తున్నాము, ఇది ఇన్‌పుట్ డేటాలో కొంత భాగాన్ని ప్రాసెస్ చేస్తున్నప్పుడు మొత్తం “మల్టీటాస్కింగ్” ప్రక్రియను నిలిపివేసింది. మరియు దీనికి ముందు నిర్గమాంశ చాలా తక్కువగా ఉన్నందున మాత్రమే సమస్యలకు దారితీయలేదు.
నేను ఈ టాస్క్ మెకానిజంను వివరించాను ఎందుకంటే రెండెజౌస్ అభ్యర్థించబడినప్పుడు లేదా పూర్తి చేయాలని భావించినప్పుడు, "టాస్క్ స్విచ్" సంభవించవచ్చు. అంటే, ప్రాసెసర్ అమలు చేయడానికి సిద్ధంగా ఉన్న మరొక పనిని ప్రాసెస్ చేయడం ప్రారంభించవచ్చు. ఒక పని మరొక పనితో సమావేశానికి సిద్ధంగా ఉన్నప్పుడు, పూర్తిగా భిన్నమైన పనిని అమలు చేయడం ప్రారంభించవచ్చు మరియు చివరికి మొదటి రెండెజౌస్‌కు రాబడిని నియంత్రించవచ్చు. మరియు పని మారడానికి కారణమయ్యే ఇతర సంఘటనలు సంభవించవచ్చు; మ్యూటెక్స్‌ని ప్రింటింగ్ లేదా ఎగ్జిక్యూట్ చేయడం వంటి సిస్టమ్ ఫంక్షన్‌కి కాల్ చేయడం అటువంటి ఈవెంట్.
ఏ లైన్ కోడ్ సమస్యకు కారణమైందో అర్థం చేసుకోవడానికి, నేను టాస్క్ స్విచ్‌ని ట్రిగ్గర్ చేయకుండా స్టేట్‌మెంట్‌ల శ్రేణి ద్వారా పురోగతిని రికార్డ్ చేయడానికి ఒక మార్గాన్ని కనుగొనవలసి ఉంది, ఇది క్రాష్ సంభవించకుండా చేస్తుంది. కాబట్టి నేను ప్రయోజనం పొందలేకపోయాను Put_Line()I/O ఆపరేషన్లు చేయకుండా ఉండటానికి. నేను కౌంటర్ వేరియబుల్ లేదా అలాంటిదే సెట్ చేయగలను, కానీ నేను దానిని స్క్రీన్‌పై ప్రదర్శించలేకపోతే దాని విలువను ఎలా చూడగలను?
అలాగే, లాగ్‌ను పరిశీలిస్తున్నప్పుడు, హృదయ స్పందన సందేశాల ప్రాసెసింగ్ వేలాడదీయబడినప్పటికీ, ప్రక్రియ యొక్క అన్ని I/O ఆపరేషన్‌లను నిరోధించి, ఇతర ప్రాసెసింగ్‌ను నిర్వహించకుండా నిరోధించినప్పటికీ, ఇతర స్వతంత్ర పనులు అమలు చేయబడుతూనే ఉన్నాయని తేలింది. అంటే, పని పూర్తిగా నిరోధించబడలేదు, (క్లిష్టమైన) పనుల గొలుసు మాత్రమే.
నిరోధించే వ్యక్తీకరణను అంచనా వేయడానికి ఇది అవసరమైన క్లూ.
నేను ఒక అడా ప్యాకేజీని తయారు చేసాను, ఇందులో టాస్క్, ఎన్యూమరేట్ చేయబడిన రకం మరియు ఆ రకమైన గ్లోబల్ వేరియబుల్ ఉన్నాయి. లెక్కించదగిన అక్షరాలు సమస్యాత్మక క్రమం యొక్క నిర్దిష్ట వ్యక్తీకరణలకు కట్టుబడి ఉంటాయి (ఉదా. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), ఆపై గ్లోబల్ వేరియబుల్‌కు సంబంధిత గణనను కేటాయించిన అసైన్‌మెంట్ ఎక్స్‌ప్రెషన్‌లను అందులో చొప్పించారు. వీటన్నింటి యొక్క ఆబ్జెక్ట్ కోడ్ మెమరీలో స్థిరంగా నిల్వ చేయబడినందున, దాని అమలు ఫలితంగా పని మారడం చాలా అసంభవం. టాస్క్‌ను తిరిగి మార్చేటప్పుడు (అనేక కారణాల వల్ల) తిరిగి వచ్చే బదులు అమలులో నిరోధించడం జరిగినందున, టాస్క్‌ను మార్చగల వ్యక్తీకరణలను మేము ప్రాథమికంగా అనుమానించాము.
ట్రాకింగ్ టాస్క్ కేవలం లూప్‌లో రన్ అవుతుంది మరియు గ్లోబల్ వేరియబుల్ విలువ మారిందో లేదో తెలుసుకోవడానికి క్రమానుగతంగా తనిఖీ చేయబడుతుంది. ప్రతి మార్పుతో, విలువ ఫైల్‌లో సేవ్ చేయబడింది. తర్వాత కొద్దిసేపు వేచి ఉండి కొత్త చెక్. నేను ఫైల్‌కు వేరియబుల్‌ను వ్రాసాను ఎందుకంటే సమస్య ప్రాంతంలో పనిని మార్చేటప్పుడు సిస్టమ్ దానిని అమలు చేయడానికి ఎంచుకున్నప్పుడు మాత్రమే పని అమలు చేయబడుతుంది. ఈ టాస్క్‌లో ఏమి జరిగినా, ఇతర, సంబంధం లేని బ్లాక్ చేయబడిన టాస్క్‌లను ప్రభావితం చేయదు.
సిస్టమ్ సమస్యాత్మక కోడ్‌ని అమలు చేసే స్థాయికి చేరుకున్నప్పుడు, ప్రతి తదుపరి వ్యక్తీకరణకు వెళ్లేటప్పుడు గ్లోబల్ వేరియబుల్ రీసెట్ చేయబడుతుంది. అప్పుడు టాస్క్ మారడానికి కారణమయ్యే ఏదో జరుగుతుంది మరియు దాని ఎగ్జిక్యూషన్ ఫ్రీక్వెన్సీ (10 Hz) పర్యవేక్షణ టాస్క్ కంటే తక్కువగా ఉన్నందున, మానిటర్ గ్లోబల్ వేరియబుల్ యొక్క విలువను సంగ్రహించి దానిని వ్రాయగలదు. సాధారణ పరిస్థితిలో, నేను గణనల ఉపసమితి యొక్క పునరావృత క్రమాన్ని పొందగలను: టాస్క్ స్విచ్ సమయంలో వేరియబుల్ యొక్క చివరి విలువలు. వేలాడుతున్నప్పుడు, గ్లోబల్ వేరియబుల్ ఇకపై మారకూడదు మరియు చివరిగా వ్రాసిన విలువ ఏ వ్యక్తీకరణ పూర్తి కాలేదని సూచిస్తుంది.
నేను ట్రాకింగ్‌తో కోడ్‌ని అమలు చేసాను. అతను స్తంభించిపోయాడు. మరియు పర్యవేక్షణ క్లాక్ వర్క్ లాగా పనిచేసింది.
లాగ్ ఊహించిన క్రమాన్ని కలిగి ఉంది, ఇది మ్యూటెక్స్ అని పిలవబడిందని సూచించే విలువ ద్వారా అంతరాయం కలిగింది Unlock, మరియు పని పూర్తి కాలేదు - వేలకొద్దీ మునుపటి కాల్‌ల మాదిరిగానే.
అపెక్స్ ఇంజనీర్లు ఈ సమయంలో వారి కోడ్‌ను తీవ్రంగా విశ్లేషించారు మరియు మ్యూటెక్స్‌లో సిద్ధాంతపరంగా లాక్ సంభవించే స్థలాన్ని కనుగొన్నారు. కానీ దాని సంభావ్యత చాలా తక్కువగా ఉంది, ఎందుకంటే ఒక నిర్దిష్ట సమయంలో సంభవించే సంఘటనల యొక్క నిర్దిష్ట క్రమం మాత్రమే నిరోధించడానికి దారితీస్తుంది. మర్ఫీస్ లా, అబ్బాయిలు, ఇది మర్ఫీస్ లా.
నాకు అవసరమైన కోడ్ ముక్కను రక్షించడానికి, నేను మ్యూటెక్స్ ఫంక్షన్ కాల్‌లను (OS మ్యూటెక్స్ ఫంక్షనాలిటీ పైన నిర్మించబడింది) ఆ భాగానికి మ్యూటెక్స్ యాక్సెస్‌ని నియంత్రించడానికి చిన్న స్థానిక అడా మ్యూటెక్స్ ప్యాకేజీతో భర్తీ చేసాను.
నేను దానిని కోడ్‌లోకి చొప్పించాను మరియు పరీక్షను అమలు చేసాను. ఏడు గంటల తర్వాత కోడ్ పని చేస్తూనే ఉంది.
నా కోడ్ రేషనల్‌కి సమర్పించబడింది, అక్కడ వారు దానిని కంపైల్ చేసి, విడదీసి, సమస్యాత్మక మ్యూటెక్స్ ఫంక్షన్‌లలో ఉపయోగించిన అదే విధానాన్ని ఉపయోగించలేదని తనిఖీ చేసారు.
ఇది నా కెరీర్‌లో అత్యంత రద్దీగా ఉండే కోడ్ రివ్యూ 🙂 నాతో పాటు గదిలో దాదాపు పది మంది ఇంజనీర్లు మరియు మేనేజర్‌లు ఉన్నారు, మరో పది మంది కాన్ఫరెన్స్ కాల్‌లో ఉన్నారు - మరియు వారంతా దాదాపు 20 లైన్ల కోడ్‌ని పరిశీలించారు.
కోడ్ సమీక్షించబడింది, కొత్త ఎక్జిక్యూటబుల్ ఫైల్‌లు అసెంబుల్ చేయబడ్డాయి మరియు అధికారిక రిగ్రెషన్ పరీక్ష కోసం సమర్పించబడ్డాయి. కొన్ని వారాల తర్వాత, కౌంట్‌డౌన్ పరీక్ష విజయవంతమైంది మరియు రాకెట్ బయలుదేరింది.
సరే, అదంతా బాగానే ఉంది, అయితే కథలోని ఉద్దేశ్యం ఏమిటి?
ఇది పూర్తిగా అసహ్యకరమైన సమస్య. వందల వేల లైన్ల కోడ్, సమాంతర అమలు, డజనుకు పైగా ఇంటరాక్టింగ్ ప్రాసెస్‌లు, పేలవమైన ఆర్కిటెక్చర్ మరియు పేలవమైన అమలు, ఎంబెడెడ్ సిస్టమ్‌ల కోసం ఇంటర్‌ఫేస్‌లు మరియు మిలియన్ల డాలర్లు ఖర్చు చేయబడ్డాయి. ఒత్తిడి లేదు, సరియైనది.
నేను పోర్టింగ్ చేస్తున్నందున నేను దృష్టిలో ఉన్నప్పటికీ, ఈ సమస్యపై నేను మాత్రమే పని చేయలేదు. కానీ నేను దీన్ని చేసినప్పటికీ, నేను వందల వేల పంక్తుల కోడ్‌ను అర్థం చేసుకున్నానని లేదా వాటిని తగ్గించానని అర్థం కాదు. కోడ్ మరియు లాగ్‌లను దేశవ్యాప్తంగా ఉన్న ఇంజనీర్లు విశ్లేషించారు, కానీ వారు వైఫల్యానికి గల కారణాల గురించి వారి ఊహలను నాకు చెప్పినప్పుడు, వాటిని తిరస్కరించడానికి నాకు అర నిమిషం పట్టింది. మరియు నేను సిద్ధాంతాలను విశ్లేషించమని అడిగినప్పుడు, నేను దానిని మరొకరికి పంపుతాను, ఎందుకంటే ఈ ఇంజనీర్లు తప్పు మార్గంలో వెళ్తున్నారని నాకు స్పష్టంగా కనిపించింది. అహంకారం కదూ? అవును, ఇది నిజం, కానీ నేను మరొక కారణం కోసం పరికల్పనలు మరియు అభ్యర్థనలను తిరస్కరించాను.
సమస్య స్వరూపం నాకు అర్థమైంది. ఇది ఎక్కడ జరుగుతుందో లేదా ఎందుకు జరుగుతుందో నాకు ఖచ్చితంగా తెలియదు, కానీ ఏమి జరుగుతుందో నాకు తెలుసు.
సంవత్సరాలుగా, నేను చాలా జ్ఞానం మరియు అనుభవాన్ని సేకరించాను. నేను అడాను ఉపయోగించడంలో మార్గదర్శకులలో ఒకడిని మరియు దాని ప్రయోజనాలు మరియు అప్రయోజనాలు అర్థం చేసుకున్నాను. అడా రన్‌టైమ్ లైబ్రరీలు టాస్క్‌లను ఎలా నిర్వహిస్తాయో మరియు సమాంతర అమలుతో ఎలా వ్యవహరిస్తాయో నాకు తెలుసు. మరియు నేను మెమరీ, రిజిస్టర్లు మరియు అసెంబ్లర్ స్థాయిలో తక్కువ-స్థాయి ప్రోగ్రామింగ్‌ను అర్థం చేసుకున్నాను. మరో మాటలో చెప్పాలంటే, నా రంగంలో నాకు లోతైన జ్ఞానం ఉంది. మరియు సమస్య యొక్క కారణాన్ని కనుగొనడానికి నేను వాటిని ఉపయోగించాను. నేను బగ్ చుట్టూ పని చేయలేదు, చాలా సున్నితమైన రన్‌టైమ్ వాతావరణంలో దీన్ని ఎలా కనుగొనాలో నేను అర్థం చేసుకున్నాను.
అటువంటి పోరాటం యొక్క లక్షణాలు మరియు పరిస్థితులతో పరిచయం లేని వారికి కోడ్‌తో పోరాట కథనాలు చాలా ఆసక్తికరంగా లేవు. కానీ నిజంగా కష్టమైన సమస్యలను పరిష్కరించడానికి ఏమి అవసరమో అర్థం చేసుకోవడానికి ఈ కథలు మాకు సహాయపడతాయి.
నిజంగా కష్టమైన సమస్యలను పరిష్కరించడానికి, మీరు ప్రోగ్రామర్ కంటే ఎక్కువగా ఉండాలి. మీరు కోడ్ యొక్క "విధి", దాని పర్యావరణంతో ఎలా సంకర్షణ చెందుతుంది మరియు పర్యావరణం ఎలా పనిచేస్తుందో మీరు అర్థం చేసుకోవాలి.
ఆపై మీరు మీ స్వంత శిధిలమైన సెలవు వారాన్ని కలిగి ఉంటారు.
కొనసాగించాలి.
మూలం: www.habr.com