Iki minangka pilihan crita saka Internet babagan carane kewan omo kadhangkala duwe manifestasi sing luar biasa. Mbok menawa sampeyan uga duwe prekara.
Alergi mobil kanggo es krim vanilla
Crita kanggo para insinyur sing ngerti manawa sing jelas ora mesthi dadi jawaban, lan sanajan kasunyatane adoh banget, dheweke isih dadi kasunyatan. Divisi Pontiac General Motors Corporation nampa keluhan:
Iki kaping pindho aku nulis kanggo sampeyan, lan aku ora nyalahke sampeyan ora mangsuli, amarga muni edan. Kulawarga kita duwe tradisi mangan es krim saben wengi sawise nedha bengi. Jinis es krim saben-saben ganti, lan sawise nedha bengi, kabeh kulawarga milih es krim sing arep dituku, sawise aku menyang toko. Aku bubar tuku Pontiac anyar lan wiwit iku lelungan kanggo njaluk es krim wis dadi masalah. Sampeyan ndeleng, saben aku tuku es krim vanilla lan bali saka toko, mobil ora bisa miwiti. Yen aku nggawa es krim liyane, mobil diwiwiti tanpa masalah. Aku pengin takon pitakonan serius, ora ketompo carane bodho muni: "Apa iku Pontiac sing ndadekake ora miwiti nalika nggawa es krim vanilla, nanging wiwit gampang nalika nggawa roso liyane saka es krim?"
Kaya sing sampeyan bayangake, presiden divisi kasebut mamang babagan surat kasebut. Nanging, ing kasus, aku ngirim insinyur kanggo mriksa. Dhèwèké kagèt merga ketemu karo wong sing sugih lan pinter urip ing tlatah sing éndah. Padha sarujuk kanggo ketemu langsung sawise nedha bengi supaya wong loro bisa menyang toko kanggo es krim. Ing wayah sore iku vanilla, lan nalika padha bali menyang mobil, iku ora bakal miwiti.
Insinyur teka telung sore maneh. Sepisanan es krim iku coklat. Mobil diwiwiti. Kaping pindho ana es stroberi. Mobil diwiwiti. Ing wayah sore katelu dheweke njaluk njupuk vanilla. Mobil ora diwiwiti.
Nalar kanthi rasional, insinyur kasebut ora percaya yen mobil kasebut alergi es krim vanila. Mula, aku setuju karo sing duwe mobil yen dheweke bakal nerusake kunjungan nganti dheweke nemokake solusi kanggo masalah kasebut. Lan ing sadawane dalan, dheweke wiwit njupuk cathetan: dheweke nulis kabeh informasi, wektu, jinis bensin, wektu tekan lan bali saka toko, lsp.
Insinyur enggal nyadari yen pemilik mobil mbuwang wektu kurang kanggo tuku es krim vanilla. Alesane yaiku tata letak barang ing toko. Es krim vanilla sing paling populer lan disimpen ing mesin pembeku sing kapisah ing ngarep toko supaya luwih gampang ditemokake. Lan kabeh varieties liyane ana ing mburi toko, lan njupuk luwih akeh wektu kanggo nemokake macem-macem tengen lan mbayar.
Saiki pitakonan kanggo insinyur: kenapa mobil ora diwiwiti yen kurang wektu wis liwati wiwit mesin dipateni? Wiwit masalah iku wektu, ora es krim vanilla, engineer cepet nemokake jawaban: iku kunci gas. Iki kedadeyan saben sore, nanging nalika pemilik mobil ngentekake wektu luwih akeh kanggo nggoleki es krim, mesin kasebut bisa dadi adhem lan gampang diwiwiti. Lan nalika wong tuku es krim vanilla, mesin isih panas banget lan kunci gas ora duwe wektu kanggo larut.
Moral: Malah masalah edan banget kadhangkala nyata.
kacilakan Bandicoot
Iku nglarani kanggo ngalami iki. Minangka programmer, sampeyan njaluk digunakake kanggo nyalahke kode pisanan, kaloro, katelu ... lan nang endi wae ing Panggonan sepuluh ewu sampeyan nyalahke compiler. Lan luwih mudhun dhaptar sampeyan wis nyalahake peralatan kasebut.
Mangkene critaku babagan bug hardware.
Kanggo game Crash Bandicoot, aku nulis kode kanggo mbukak lan nyimpen menyang kertu memori. Kanggo pangembang game sing kaya ngono, kaya mlaku-mlaku ing taman: Aku ngira yen bakal ditindakake sawetara dina. Nanging, aku rampung debugging kode kanggo enem minggu. Sadawane dalan, aku ngatasi masalah liyane, nanging saben dina aku bali menyang kode iki kanggo sawetara jam. Iku sengsara.
Gejala katon kaya iki: nalika sampeyan nyimpen playthrough saiki game lan ngakses kertu memori, kabeh meh tansah dadi apik ... Nanging kadhangkala maca utawa nulis wektu entek operasi tanpa alesan ketok. Rekaman singkat asring ngrusak kertu memori. Nalika pemain nyoba kanggo nyimpen, kang ora mung gagal kanggo nyimpen, nanging uga numpes peta. Ngakak.
Sawise sawetara wektu, produser kita ing Sony, Connie Bus, wiwit gupuh. Kita ora bisa ngirim game karo bug iki, lan enem minggu mengko aku ora ngerti apa iki nyebabake masalah. Liwat Connie, kita ngubungi pangembang PS1 liyane: apa ana sing nemoni sing padha? Ora. Ora ana sing duwe masalah karo kertu memori.
Yen sampeyan ora duwe gagasan kanggo debugging, siji-sijine pendekatan sing ditinggalake yaiku "dibagi lan digdaya": mbusak kode liyane lan liyane saka program sing salah nganti ana pecahan cilik sing isih nyebabake masalah. Yaiku, sampeyan ngethok program kasebut kanthi potongan nganti bagean sing ngemot bug tetep.
Nanging bab iku, iku angel banget kanggo Cut chunks metu saka video game. Carane mbukak yen mbusak kode sing emulates gravitasi? Utawa nggambar karakter?
Mulane, kita kudu ngganti kabeh modul karo stubs sing ndalang kanggo nindakake soko migunani, nanging nyatane nindakake soko banget prasaja sing ora bisa ngemot kasalahan. We kudu nulis crutches kuwi kanggo game kanggo paling bisa. Iki minangka proses sing alon lan nglarani.
Ing cendhak, aku nindakake. Aku dibusak liyane lan liyane bêsik kode nganti aku kiwa karo kode dhisikan sing configures sistem kanggo mbukak game, initializes hardware Rendering, etc. Mesthi, ing tahap iki aku ora bisa nggawe menu nyimpen lan mbukak, amarga aku kudu nggawe rintisan kanggo kabeh kode grafis. Nanging aku bisa ndalang dadi pangguna nggunakake (ora katon) layar nyimpen lan mbukak lan takon kanggo nyimpen banjur nulis menyang kertu memori.
Iki ninggalake kula karo Piece cilik saka kode sing isih masalah ndhuwur - nanging isih kedados acak! Paling asring kabeh bisa digunakake kanthi becik, nanging kadhangkala ana gangguan. Aku dibusak meh kabeh kode game, nanging bug isih urip. Iki nggumunake: kode sing isih ana ora nindakake apa-apa.
Ing sawetara wektu, mbokmenawa watara jam telu esuk, ana pikirane. Operasi maca lan nulis (input/output) kalebu wektu eksekusi sing tepat. Nalika sampeyan nggarap hard drive, kertu memori utawa modul Bluetooth, kode tingkat rendah sing tanggung jawab kanggo maca lan nulis cocog karo pulsa jam.
Kanthi bantuan jam, piranti sing ora langsung nyambung menyang prosesor disinkronake karo kode sing dieksekusi ing prosesor. Jam nemtokake baud rate-kacepetan data dikirim. Yen ana kebingungan karo wektu, mula hardware utawa piranti lunak, utawa loro-lorone, uga bingung. Lan iki ala banget, amarga data bisa rusak.
Apa yen ana ing kode kita mbingungake wektu? Aku mriksa kabeh related kanggo iki ing kode program test lan ngeweruhi sing kita nyetel timer programmable ing PS1 kanggo 1 kHz (1000 ticks per detik). Iki cukup akeh; kanthi standar, nalika konsol diwiwiti, mlaku ing 100 Hz. Lan paling game nggunakake frekuensi iki.
Andy, pangembang game, nyetel wektu kanggo 1 kHz supaya obahe bakal diwilang luwih akurat. Andy cenderung ngluwihi, lan yen kita niru gravitasi, kita nindakake kanthi akurat!
Nanging apa yen nyepetake timer Piye wae kena pengaruh wektu sakabèhé saka program, lan mulane jam sing ngatur tingkat baud kanggo kertu memori?
Aku komentar metu kode timer. Kesalahan ora kedadeyan maneh. Nanging iki ora ateges kita ndandani, amarga kegagalan kasebut kedadeyan kanthi acak. Apa yen aku mung begja?
Sawetara dina sabanjure aku nyoba maneh karo program tes. Bug kasebut ora kedadeyan maneh. Aku bali menyang basis kode game lengkap lan ngowahi kode nyimpen lan mbukak supaya timer programmable bakal ngreset menyang Nilai asli (100Hz) sadurunge ngakses kertu memori, lan banjur ngreset maneh kanggo 1kHz. Ora ana kacilakan maneh.
Nanging kenapa iki kedadeyan?
Aku bali menyang program test maneh. Aku nyoba kanggo golek sawetara pola ing kedadean saka kesalahan karo 1 kHz timer. Pungkasane aku ngeweruhi sing kesalahan occurs nalika wong muter karo controller PS1. Amarga aku arang banget nindakake iki - kenapa aku butuh pengontrol nalika nyoba nyimpen lan mbukak kode? - Aku malah ora sok dong mirsani katergantungan iki. Nanging ing sawijining dina, salah sawijining seniman kita ngenteni aku rampung tes - aku bisa uga ngipat-ipati nalika iku - lan gugup nggegirisi pengontrol ing tangane. Ana kesalahan. “Tunggu, apa?!” Nah, gawe maneh!”
Nalika aku temen maujud sing loro acara iki interconnected, Aku bisa gampang ngasilake kesalahan: Aku miwiti ngrekam menyang kertu memori, dipindhah controller, lan ngrusak kertu memori. Kanggo kula katon kaya bug hardware.
Aku teka menyang Connie lan ngandhani dheweke babagan panemuanku. Dheweke ngirim informasi kasebut menyang salah sawijining insinyur sing ngrancang PS1. "Mokal," wangsulane, "Ora bisa dadi masalah hardware." Aku takon Connie kanggo ngatur obrolan kanggo kita.
Insinyur kasebut nimbali aku lan kita bantah nganggo basa Inggris sing rusak lan basa Jepangku (banget). Akhire aku kandha, "Ayo kula ngirim program tes baris 30 sing mindhah pengontrol nyebabake bug." Dheweke sarujuk. Ngandika iku sampah wektu lan dheweke sibuk banget nggarap proyek anyar, nanging bakal menehi amarga kita pangembang penting banget kanggo Sony. Aku ngresiki program test lan dikirim menyang dheweke.
Ing wayah sore sabanjure (kita ana ing Los Angeles lan dheweke ana ing Tokyo) dheweke nelpon aku lan njaluk ngapura. Iku masalah hardware.
Aku ora ngerti apa persis bug, nanging saka apa aku krungu ing markas Sony, yen sampeyan nyetel wektu kanggo Nilai cukup dhuwur, interfered karo komponen ing motherboard ing n sekitare kristal wektu. Salah sijine yaiku pengontrol tingkat baud kanggo kertu memori, sing uga nyetel tingkat baud kanggo pengontrol. Aku dudu insinyur, mula aku bisa uga ngganggu.
Nanging ing ngisor iki ana gangguan antarane komponen ing motherboard. Lan nalika ngirim data bebarengan liwat port controller lan port kertu memori karo timer mlaku ing 1 kHz, bit ilang, data ilang, lan kertu rusak.
Sapi ala
Ing taun 1980-an, mentorku Sergei nulis piranti lunak kanggo SM-1800, klon Soviet saka PDP-11. Mikrokomputer iki lagi wae dipasang ing stasiun sepur cedhak Sverdlovsk, pusat transportasi penting ing USSR. Sistem anyar iki dirancang kanggo rute gerbong lan lalu lintas barang. Nanging ana bug sing ngganggu sing nyebabake kacilakan lan kacilakan acak. Falls mesthi kedadeyan nalika ana wong mulih ing wayah sore. Nanging senadyan diselidiki pepek dina sabanjuré, komputer makarya kanthi bener ing kabeh tes manual lan otomatis. Iki biasane nuduhake kahanan balapan utawa sawetara bug kompetitif liyane sing kedadeyan ing kahanan tartamtu. Kesel nelpon ing wayah wengi, Sergei mutusake kanggo njaluk menyang ngisor, lan pisanan kabeh, ngerti apa kahanan ing yard marshalling mimpin kanggo risak komputer.
Kaping pisanan, dheweke nglumpukake statistik kabeh musim gugur sing ora dingerteni lan nggawe grafik miturut tanggal lan wektu. Pola kasebut ketok. Sawise ngamati sawetara dina, Sergei nyadari yen dheweke bisa kanthi gampang prédhiksi wektu kegagalan sistem ing mangsa ngarep.
Dheweke langsung ngerti manawa gangguan mung kedadeyan nalika stasiun kasebut ngurutake gerbong sapi saka Ukraina sisih lor lan Rusia sisih kulon menyang papan jagal sing cedhak. Iki dhewe aneh, amarga omah jagal disedhiyakake dening peternakan sing luwih cedhak, ing Kazakhstan.
Pembangkit listrik tenaga nuklir Chernobyl mbledhos ing taun 1986, lan kejatuhan radioaktif nyebabake wilayah sekitar ora bisa dienggoni. Wilayah sing wiyar ing Ukraina lor, Belarus lan Rusia kulon wis kontaminasi. Nganggep tingkat radiasi sing dhuwur ing gerbong sing teka, Sergei ngembangake cara kanggo nguji teori iki. Populasi dilarang duwe dosimeter, mula Sergei ndhaptar awake dhewe karo sawetara prajurit militer ing stasiun sepur. Sawise pirang-pirang ombenan vodka, dheweke bisa ngyakinake prajurit kanggo ngukur tingkat radiasi ing salah sawijining gerbong sing curiga. Ternyata level kasebut kaping pirang-pirang luwih dhuwur tinimbang nilai normal.
Ora mung sapi emit akeh radiation, tingkat dhuwur banget sing mimpin kanggo mundhut acak saka bit ing memori SM-1800, kang dumunung ing bangunan jejere stasiun.
Ana kekurangan pangan ing USSR, lan panguwasa mutusake kanggo nyampur daging Chernobyl karo daging saka wilayah liyane ing negara. Iki ndadekake iku bisa kanggo ngurangi tingkat sakabèhé saka radioaktivitas tanpa kelangan sumber daya terkenal. Sawise sinau babagan iki, Sergei langsung ngisi dokumen kanggo emigrasi. Lan kacilakan komputer mandheg dhewe nalika tingkat radiasi mudhun saka wektu.
Liwat pipa
Biyen, Movietech Solutions nggawe piranti lunak kanggo bioskop, dirancang kanggo akuntansi, penjualan tiket lan manajemen umum. Versi DOS saka aplikasi unggulan cukup populer ing antarane rantai bioskop cilik lan agêng ing Amerika Utara. Dadi ora nggumunake yen versi Windows 95 diumumake, terintegrasi karo layar tutul paling anyar lan kios layanan mandiri, lan dilengkapi karo macem-macem alat pelaporan, cepet dadi populer. Paling asring nganyari tanpa masalah. Staff IT lokal nginstal peralatan anyar, data migrasi, lan bisnis terus. Kajaba nalika iku ora langgeng. Nalika kedadeyan kasebut, perusahaan bakal ngirim James, sing dijuluki "The Cleaner."
Senajan julukan nyaranake jinis nefarious, resik mung kombinasi instruktur, installer lan jack-of-all-trades. James bakal nglampahi sawetara dina ing situs klien sijine kabeh komponen bebarengan, lan banjur nglampahi saperangan dina liyane mulang Staff carane nggunakake sistem anyar, mecahaken sembarang masalah hardware sing njedhul lan ateges bantuan piranti lunak liwat sawijining bayi.
Mula, ora nggumunake yen ing wektu sing sibuk iki, James teka ing kantor ing wayah esuk, lan sadurunge tekan mejane, dheweke disambut dening manajer, diisi kafein ngluwihi biasanipun.
"Aku wedi sampeyan kudu menyang Annapolis, Nova Scotia, sanalika bisa." Kabeh sistem mudhun, lan sawise sewengi nggarap insinyur, kita ora bisa ngerti apa sing kedadeyan. Katon kaya jaringan wis gagal ing server. Nanging mung sawise sistem wis mlaku sawetara menit.
— Padha ora bali menyang sistem lawas? - James mangsuli rampung serius, sanajan mental kang widened mripate kaget.
- Persis: spesialis IT "ngganti prioritas" lan mutusake ninggalake server lawas. James, dheweke nginstal sistem kasebut ing enem situs lan mung mbayar dhukungan premium, lan bisnise saiki mlaku kaya ing taun 1950-an.
James mbenerake rada.
- Iku masalah liyane. Oke, ayo miwiti.
Nalika dheweke teka ing Annapolis, sing pisanan ditindakake yaiku nemokake teater pertama pelanggan sing duwe masalah. Ing peta sing dijupuk ing bandara, kabeh katon apik, nanging wilayah ing sekitar alamat sing dikarepake katon curiga. Ora ghetto, nanging kaya film noir. Nalika James parkir ing pinggir pinggir kutha, ana pelacur nyedhaki dheweke. Amarga ukuran Annapolis, kemungkinan mung siji-sijine ing kutha kasebut. Penampilan dheweke langsung ngelingi karakter sing misuwur sing nawakake jinis dhuwit ing layar lebar. Ora, ora babagan Julia Roberts, nanging babagan Jon Voight [allusion kanggo film "Midnight Cowboy" - approx. jalur].
Sawise dikirim perek ing dalan, James tindak menyang bioskop. Ing saubengé wis saya apik, nanging isih menehi kesan sing mlayu mudhun. Ora James kuwatir banget. Dheweke wis tau menyang papan sing ala sadurunge. Lan iki Kanada, ngendi malah muggers cukup sopan kanggo ngomong "matur nuwun" sawise njupuk dompet.
Lawang sisih kiwa menyang bioskop ana ing gang lank. James mlaku menyang lawang lan thothok-thothok. Ora let suwe creaked lan mbukak rada.
- Apa sampeyan ngresiki? - swara serak teka saka njero.
- Ya, iki aku ... Aku teka kanggo ndandani kabeh.
James mlaku menyang lobi bioskop. Ketoke ora duwe pilihan liyane, staf wiwit menehi karcis kertas kanggo pengunjung. Iki nggawe laporan keuangan angel, apamaneh rincian sing luwih menarik. Nanging staf disambut James kanthi lega lan langsung nggawa dheweke menyang kamar server.
Ing kawitan marketing, kabeh iku apik. James mlebu ing server lan mriksa panggonan curiga biasanipun. Ora masalah. Nanging, saka turah mbrawah saka ati-ati, James mati server, ngganti kertu jaringan, lan mbalek maneh sistem. Dheweke langsung miwiti kerja kanthi lengkap. Staff wiwit adol tiket maneh.
James nelpon Mark lan ngandhani babagan kahanan kasebut. Ora angel mbayangake manawa James pengin tetep lan ndeleng manawa ana kedadeyan sing ora dikarepake. Dheweke mudhun ing undhak-undhakan lan wiwit takon marang karyawan apa sing kedadeyan. Temenan sistem wis mandheg kerja. Padha dipateni lan ing, kabeh bisa. Nanging sawise 10 menit sistem ambruk.
Mung ing wayahe iki kedadeyan sing padha. Dumadakan, sistem tiket wiwit mbuwang kesalahan. Petugas kasebut ngempet lan njupuk karcis kertas, lan James cepet-cepet menyang ruang server. Kabeh katon apik karo server.
Banjur salah sijine karyawan mlebu.
- Sistem bisa digunakake maneh.
James bingung amarga dheweke ora nindakake apa-apa. Luwih tepate, ora ana sing bakal nggawe sistem bisa digunakake. Dheweke metu, ngangkat telpon, lan nelpon saluran dhukungan perusahaan. Ora let suwe karyawan sing padha mlebu ruangan server.
- Sistem mudhun.
James nglirik server. Pola sing menarik lan akrab saka macem-macem warna sing nari ing layar - pipa sing semrawut lan intertwining. Kita kabeh wis ndeleng screensaver iki ing sawetara titik. Iku apik render lan secara harfiah hypnotizing.
James menet tombol lan pola kasebut ilang. Dheweke cepet-cepet menyang kantor tiket lan ing dalan ketemu karo karyawan sing bali menyang dheweke.
- Sistem bisa digunakake maneh.
Yen sampeyan bisa nindakake facepalm mental, iku persis apa James. Screensaver. Iku nggunakake OpenGL. Lan mulane, sajrone operasi, nggunakake kabeh sumber daya prosesor server. Akibaté, saben telpon menyang server rampung karo wektu entek.
James bali menyang kamar server, mlebu, lan ngganti screensaver karo pipo ayu karo layar kosong. Yaiku, tinimbang screensaver sing nggunakake 100% sumber daya prosesor, aku nginstal liyane sing ora nggunakake sumber daya. Banjur aku ngenteni 10 menit kanggo mriksa tebakanku.
Nalika James teka ing bioskop sabanjuré, dheweke kepingin weruh carane nerangake marang manajer dheweke yen dheweke lagi mabur 800 km kanggo mateni screen saver.
Kacilakan sajrone fase rembulan tartamtu
Cerito nyoto. Sawijining dina muncul bug piranti lunak sing gumantung marang fase rembulan. Ana rutinitas cilik sing umum digunakake ing macem-macem program MIT kanggo ngetung perkiraan kanggo fase Bulan sing bener. GLS nggawe rutinitas iki dadi program LISP sing, nalika nulis file, bakal ngasilake baris kanthi cap wektu meh 80 karakter. Arang banget yen baris pisanan pesen bakal dadi dawa banget lan mimpin menyang baris sabanjure. Lan nalika program mengko maca file iki, iku ipat-ipat. Dawane baris pisanan gumantung ing tanggal lan wektu sing tepat, uga dawa spesifikasi fase nalika cap wektu dicithak. Yaiku, bug kasebut gumantung saka fase rembulan!
Edisi kertas pisanan (Steele-1983) ngemot conto baris kasebut sing nyebabake bug sing diterangake, nanging panyetel huruf "mbenerake". Iki wiwit diterangake minangka "bug fase rembulan".
Nanging, ati-ati karo asumsi. Sawetara taun kepungkur, insinyur saka CERN (Pusat Riset Nuklir Eropa) nemoni kesalahan ing eksperimen sing ditindakake ing Collider Electron-Positron Besar. Wiwit komputer kanthi aktif ngolah data sing akeh banget sing diasilake dening piranti iki sadurunge nuduhake asil kasebut marang para ilmuwan, akeh sing ngira yen piranti lunak kasebut sensitif marang fase rembulan. Sawetara insinyur nekat entuk dhasar bebener. Kesalahan muncul amarga owah-owahan tipis ing geometri cincin dawane 27 km amarga deformasi Bumi nalika ngliwati Bulan! Crita iki wis mlebu folklor fisika minangka "Newton's Revenge on Particle Physics" lan conto hubungan antara hukum fisika sing paling gampang lan paling tuwa lan konsep ilmiah sing paling maju.
Siram jamban mandheg sepur
Bug hardware paling apik sing wis dakrungu yaiku ing sepur kacepetan dhuwur ing Prancis. Bug kasebut nyebabake rem darurat ing sepur, nanging mung yen ana penumpang. Ing saben kasus kasebut, sepur kasebut dicopot saka layanan, dipriksa, nanging ora ana sing ditemokake. Banjur dheweke dikirim maneh menyang baris, lan dheweke langsung nabrak mandheg.
Sajrone salah sawijining pemeriksaan, insinyur sing numpak sepur menyang jamban. Dheweke enggal-enggal adus, BOOM! Mandeg darurat.
Insinyur kasebut ngubungi sopir lan takon:
- Apa sing sampeyan tindakake sadurunge ngerem?
- Inggih, kula mudhun alon-alon ...
Iki aneh, amarga sajrone operasi normal, sepur mudhun kaping pirang-pirang mudhun. Sepur kasebut maju, lan nalika mudhun, sopir kasebut ngelingake:
- Aku arep alon mudhun.
Ora ana kedadeyan.
- Apa sing sampeyan lakoni sajrone rem pungkasan? - takon sopir.
- Lha...aku nang toilet...
- Inggih, banjur menyang jamban lan apa sing sampeyan tindakake nalika kita mudhun maneh!
Insinyur kasebut menyang jamban, lan nalika sopir ngelingake: "Aku alon-alon," dheweke nyusup banyu. Mesthi, sepur langsung mandheg.
Saiki dheweke bisa ngasilake masalah kasebut lan kudu nemokake sababe.
Sawise rong menit, padha ngeweruhi sing engine brake kabel remot kontrol (Sepur wis siji engine ing saben mburi) iki pedhot saka tembok saka kabinèt electrical lan lying ing relay sing kontrol jamban plug solenoid... Nalika relay diuripake, nggawe gangguan ing kabel brake, lan pangayoman sistem marang gagal mung klebu rem darurat.
Gerbang sing sengit FORTRAN
Sawetara sasi kepungkur kita weruh yen sambungan jaringan ing daratan [iki ing Hawaii] saya suwe saya alon banget. Iki bisa nganti 10-15 menit lan banjur kedadeyan maneh. Sawise sawetara wektu, kancaku ngeluh marang aku yen sambungan jaringan ing daratan ing umum ora bisa. Dheweke duwe sawetara kode FORTRAN sing kudu disalin menyang mesin ing daratan, nanging ora bisa amarga "jaringan ora tahan suwe nganti upload FTP rampung."
Ya, iku nguripake metu sing Gagal jaringan dumadi nalika kolega nyoba kanggo FTP file karo kode sumber ing FORTRAN kanggo mesin ing daratan. Kita nyoba arsip file kasebut: banjur disalin kanthi lancar (nanging mesin target ora duwe unpacker, mula masalah kasebut ora ditanggulangi). Akhire kita "dibagi" kode FORTRAN menyang bêsik cilik lan dikirim siji-sijine. Akèh pecahan padha disalin tanpa masalah, nanging sawetara bêsik ora pass, utawa liwati sawise akeh usaha.
Nalika kita nliti perangan-perangan masalah, kita katutup sing padha duwe soko ing umum: kabeh padha ngemot pamblokiran komentar sing diwiwiti lan dipungkasi karo baris sing kasusun saka ibukutha C (minangka kolega seneng komentar ing FORTRAN). Kita ngirim email menyang pakar jaringan ing daratan lan njaluk bantuan. Mesthi, dheweke pengin ndeleng conto file kita sing ora bisa ditransfer liwat FTP ... nanging surat kita ora tekan. Akhire kita teka munggah karo prasaja nggambarakekaya apa file sing ora bisa ditransfer. Iku makarya :) [Wani aku nambah conto salah siji saka masalah FORTRAN komentar kene? Mbokmenawa ora pantes!]
Ing pungkasan kita bisa ngerteni. A gateway anyar iki bubar diinstal antarane bagean kita kampus lan jaringan daratan. Iku angel banget ngirim paket sing ngemot bit huruf C sing bola-bali! Mung sawetara saka paket iki bisa njupuk kabeh sumber daya gateway lan nyegah paling paket liyane saka liwat. Kita sambat menyang pabrikan gateway ... lan padha mangsuli: "Oh, ya, sampeyan lagi ngadhepi bug C sing bola-bali! Kita wis ngerti babagan dheweke." We pungkasanipun ditanggulangi masalah kanthi tuku gateway anyar saka pabrikan liyane (ing mantan nimbali, kasekengan kanggo nransfer program FORTRAN bisa dadi kauntungan kanggo sawetara!).
kaping angel
Sawetara taun kepungkur, nalika nggarap sistem ETL ing Perl kanggo nyuda biaya uji klinis fase 40, aku kudu ngolah udakara 000 tanggal. Loro-lorone ora lulus tes. Iki ora ngganggu aku amarga tanggal kasebut dijupuk saka data sing disedhiyakake klien sing asring, mesthi kaget. Nanging nalika mriksa data asli, jebul tanggal kasebut tanggal 1 Januari 2011 lan 1 Januari 2007. Aku mikir yen bug kasebut ana ing program sing wis daktulis, nanging ternyata umure wis 30 taun. lawas. Iki bisa uga katon misterius kanggo wong sing ora ngerti ekosistem piranti lunak. Amarga keputusane perusahaan liyane sing wis suwe golek dhuwit, klienku mbayar kula kanggo ndandani bug sing ditindakake dening salah sawijining perusahaan kanthi ora sengaja lan liyane kanthi sengaja. Kanggo sampeyan ngerti apa sing dakkandhakake, aku kudu ngomong babagan perusahaan sing nambahake fitur sing pungkasane dadi bug, uga sawetara acara menarik liyane sing nyumbang kanggo bug misterius sing dakwenehi.
Ing jaman biyen, komputer Apple kadhangkala kanthi spontan ngreset tanggale dadi 1 Januari 1904. Alesane gampang: nggunakake "jam sistem" sing nganggo baterei kanggo nglacak tanggal lan wektu. Apa sing kedadeyan nalika baterei mati? Komputer wiwit nglacak tanggal kanthi jumlah detik wiwit wiwitan jaman. Miturut jaman kita temenan tanggal asli referensi, lan kanggo Macintosh iku 1. Januari 1904. Lan sawise baterei mati, tanggal saiki direset menyang sing ditemtokake. Nanging kenapa iki kedadeyan?
Sadurunge, Apple nggunakake 32 bit kanggo nyimpen jumlah detik wiwit tanggal asli. Siji bit bisa nyimpen siji saka rong nilai - 1 utawa 0. Loro bit bisa nyimpen siji saka papat nilai: 00, 01, 10, 11. Telung bit - siji nilai saka wolung: 000, 001, 010, 011, 100 , 101, 110, 111, lsp. Lan 32 bisa nyimpen siji saka 232 nilai, yaiku 4 detik. Kanggo tanggal Apple, iki padha karo udakara 294 taun, mula Mac lawas ora bisa nangani tanggal sawise 967. Lan yen baterei sistem mati, tanggal reset kanggo 296 detik wiwit awal jaman, lan sampeyan kudu kanthi manual nyetel tanggal saben-saben sampeyan nguripake komputer (utawa nganti sampeyan tuku baterei anyar).
Nanging, keputusan Apple kanggo nyimpen tanggal minangka detik wiwit jaman kasebut tegese kita ora bisa nangani tanggal sadurunge jaman kasebut, sing duwe akibat sing akeh banget, kaya sing bakal kita deleng. Apple ngenalake fitur, dudu bug. Antarane liyane, iki tegese sistem operasi Macintosh kebal marang "bug millennium" (sing ora bisa dikandhakake babagan akeh aplikasi Mac sing duwe sistem tanggal dhewe kanggo ngatasi watesan).
Terusna. Kita nggunakake Lotus 1-2-3, "aplikasi pembunuh" IBM sing mbantu miwiti revolusi PC, sanajan komputer Apple duwe VisiCalc, sing nggawe komputer pribadi sukses. Ing keadilan, yen 1-2-3 ora katon, PC meh ora bisa dicopot, lan sejarah komputer pribadi bisa berkembang kanthi beda. Lotus 1-2-3 salah dianggep 1900 minangka taun kabisat. Nalika Microsoft ngrilis spreadsheet pisanan, Multiplan, entuk bagean cilik saka pasar. Lan nalika ngluncurake proyek Excel, dheweke mutusake ora mung nyalin skema penamaan baris lan kolom saka Lotus 1-2-3, nanging uga kanggo njamin kompatibilitas bug kanthi sengaja nganggep 1900 minangka taun kabisat. Masalah iki isih ana nganti saiki. Yaiku, ing 1-2-3 iki bug, nanging ing Excel iku kaputusan sadar sing mesthekake yen kabeh pangguna 1-2-3 bisa ngimpor tabel menyang Excel tanpa ngganti data, sanajan iku salah.
Nanging ana masalah liyane. Kaping pisanan, Microsoft ngeculake Excel kanggo Macintosh, sing ora ngenali tanggal sadurunge 1 Januari 1904. Lan ing Excel, 1 Januari 1900 dianggep minangka wiwitan jaman. Mula, para pangembang nindakake owah-owahan supaya programe bisa ngerteni jinis jaman lan data disimpen ing njerone sesuai karo jaman sing dikarepake. Microsoft malah nulis artikel panjelasan babagan iki. Lan keputusan iki nyebabake bugku.
Sistem ETLku nampa spreadsheet Excel saka pelanggan sing digawe ing Windows, nanging uga bisa digawe ing Mac. Mula, wiwitan jaman ing tabel bisa uga tanggal 1 Januari 1900, utawa 1 Januari 1904. Kepiye carane ngerteni? Format file Excel nuduhake informasi sing dibutuhake, nanging parser sing digunakake ora nuduhake (saiki), lan nganggep sampeyan ngerti jaman kanggo tabel tartamtu. Aku bisa uga wis ngginakaken liyane wektu kanggo mangerteni format binar Excel lan ngirim tembelan kanggo penulis parser, nanging aku kudu luwih akeh kanggo klien, supaya aku cepet nulis heuristik kanggo nemtokake jaman. Dheweke prasaja.
Ing Excel, tanggal 5 Juli 1998 bisa diwakili ing format "07-05-98" (sistem Amerika sing ora ana gunane), "5 Juli 98", "5 Juli 1998", "5-Jul-98" utawa sawetara format liyane. format liyane sing ora ana gunane (ironis, salah sawijining format versi Excel sing ora ditawakake yaiku ISO 8601). Nanging, ing tabel, tanggal sing ora diformat disimpen minangka "35981" kanggo epoch-1900 utawa "34519" kanggo epoch-1904 (angka kasebut nuduhake jumlah dina wiwit jaman kasebut). Aku mung nggunakake parser prasaja kanggo extract taun saka tanggal format, lan banjur nggunakake Excel parser kanggo extract taun saka tanggal unformatted. Yen nilai loro kasebut beda karo 4 taun, mula aku ngerti yen aku nggunakake sistem karo jaman-1904.
Apa aku ora mung nggunakake tanggal format? Amarga tanggal 5 Juli 1998 bisa diformat dadi "Juli, 98" karo dina sasi ilang. Kita nampa tabel saka akeh perusahaan sing nggawe wong-wong mau ing macem-macem cara sing nganti kita (ing kasus iki, kula) kanggo nemtokake tanggal. Kajaba iku, yen Excel entuk bener, mula kita kudu!
Ing wektu sing padha aku ketemu 39082. Ayo kula ngelingake sampeyan Lotus 1-2-3 dianggep 1900 taun kabisat, lan iki setya bola ing Excel. Lan wiwit iki ditambahake siji dina kanggo taun 1900, akeh fungsi pitungan tanggal bisa salah kanggo dina banget. Tegese, 39082 bisa uga tanggal 1 Januari 2011 (ing Mac) utawa 31 Desember 2006 (ing Windows). Yen "parser taun" saya ngekstrak taun 2011 saka nilai sing diformat, mula kabeh apik. Nanging amarga parser Excel ora ngerti jaman apa sing digunakake, mula dadi epoch-1900, ngasilake taun 2006. Aplikasiku weruh manawa bedane 5 taun, dianggep minangka kesalahan, mlebu log, lan ngasilake nilai sing ora diformat.
Kanggo ngubengi iki, aku nulis iki (pseudocode):
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
Banjur kabeh 40 tanggal diurai kanthi bener.
Ing tengah proyek print gedhe
Ing awal taun 1980-an, bapakku kerja ing Storage Technology, divisi sing saiki wis ora aktif sing nggawe tape drive lan sistem pneumatik kanggo feed tape kanthi kacepetan dhuwur.
Padha redesigned drive supaya padha bisa duwe siji tengah "A" drive disambungake menyang pitung drive "B", lan OS cilik ing RAM sing kontrol drive "A" bisa utusan maca lan nulis operasi kanggo kabeh "B" drive.
Saben drive "A" diwiwiti, sampeyan kudu nglebokake floppy disk menyang drive peripheral sing disambungake menyang "A" kanggo mbukak sistem operasi menyang memori. Iku banget primitif: daya komputasi diwenehake dening mikrokontroler 8-bit.
Target pamirsa kanggo peralatan kasebut yaiku perusahaan sing duwe gudang data sing gedhe banget - bank, rantai ritel, lan liya-liyane - sing kudu nyetak akeh label alamat utawa laporan bank.
Siji klien duwe masalah. Ing tengah proyek print, siji drive tartamtu "A" bisa mandheg digunakake, nyebabake kabeh proyek macet. Kanggo mulihake operasi drive, staf kudu urip maneh kabeh. Lan yen iki kedaden ing tengah tugas enem jam, jumlah ageng wektu komputer larang ilang lan jadwal kabeh operasi kaganggu.
Teknisi dikirim saka Storage Technologies. Nanging senadyan sing paling efforts , padha ora bisa ngasilake bug ing kahanan test: ketoke kedaden ing tengah proyek print gedhe. Masalah iki ora hardware, padha ngganti kabeh padha bisa: RAM, microcontroller, floppy drive, saben bagean kepikiran saka tape drive - masalah tetep.
Banjur teknisi nelpon markas lan nelpon Ahli.
Pakar kasebut njupuk kursi lan secangkir kopi, lungguh ing ruang komputer - ing jaman semana ana kamar sing dikhususake kanggo komputer - lan mirsani nalika staf antri ing karya cetak gedhe. Pakar kasebut ngenteni kegagalan - lan kedadeyan. Kabeh padha nyawang Expert, nanging dheweke ora ngerti kenapa kedadeyan kasebut. Mula dheweke dhawuh supaya antri maneh, lan kabeh karyawan lan teknisi bali kerja.
Pakar maneh lungguh ing kursi lan wiwit ngenteni gagal. Udakara enem jam liwati lan gagal. Expert maneh wis ora gagasan, kajaba sing kabeh kedaden ing kamar kapenuhan wong. Dheweke mrentahake misi kasebut diwiwiti maneh, lungguh maneh lan ngenteni.
Miturut Gagal katelu, Expert ngeweruhi soko. Gagal dumadi nalika personel ngganti kaset ing drive manca. Kajaba iku, kegagalan kasebut kedadeyan nalika salah sawijining karyawan mlaku liwat ubin tartamtu ing lantai.
Lantai sing diunggahake digawe saka ubin aluminium sing dhuwure 6 nganti 8 inci. Akeh kabel saka komputer sing mlaku ing ngisor lantai sing diunggahake kanggo nyegah sapa wae sing ora sengaja nandhang kabel penting. Kothak kasebut dipasang kanthi rapet kanggo nyegah lebu ing ngisor lantai sing diangkat.
Pakar kasebut nyadari yen salah sawijining kothak kasebut cacat. Nalika ana pegawe mlaku ing pojokan, pinggiran kothak gosok menyang kothak jejer. Bagean plastik sing nyambungake kothak uga digosok, sing nyebabake microdischarge statis sing nggawe gangguan frekuensi radio.
Dina iki, RAM luwih dilindhungi saka gangguan frekuensi radio. Nanging ing taun-taun kasebut ora kaya ngono. Pakar temen maujud sing gangguan iki ngganggu memori, lan karo operasi saka sistem operasi. Dheweke nelpon layanan dhukungan, mrentahake kothak anyar, nginstal dhewe, lan masalah kasebut ilang.
Iku pasang dhuwur!
Crita kasebut kedadeyan ing kamar server, ing lantai papat utawa kaping lima saka kantor ing Portsmouth (Aku mikir), ing area dermaga.
Sawijining dina server Unix karo database utama crash. Padha rebooted wong, nanging seneng terus tiba maneh lan maneh. Kita mutusake kanggo nelpon wong saka layanan dhukungan.
Wong sing ndhukung ... Aku rumangsa jenenge Mark, nanging ora masalah ... Aku ora ngerti dheweke. Ora masalah, tenan. Ayo tetep karo Mark, oke? gedhe.
Dadi, sawetara jam mengko Mark teka (ora adoh saka Leeds kanggo Portsmouth, sampeyan ngerti), nguripake server lan kabeh bisa tanpa masalah. Dhukungan sing khas, klien nesu banget. Mark nggoleki file log lan ora nemokake apa-apa sing ora dikarepake. Dadi Mark bali menyang sepur (utawa moda transportasi apa wae sing ditekani, bisa uga sapi pincang kanggo kabeh sing aku ngerti ... tho, ora masalah, oke?) lan bali menyang Leeds, wis boroske. dina.
Ing wayah sore sing padha server crash maneh. Critane padha ... server ora munggah. Mark nyoba bantuan saka adoh, nanging klien ora bisa miwiti server.
Sepur liyane, bis, lemon meringue utawa omong kosong liyane, lan Mark bali ing Portsmouth. Deleng, server boot tanpa masalah! Ajaib. Mark nglampahi pirang-pirang jam kanggo mriksa manawa kabeh wis cocog karo sistem operasi utawa piranti lunak lan pindhah menyang Leeds.
Around tengah dina server crash (tenang wae!). Wektu iki misale jek cukup kanggo nggawa wong support hardware kanggo ngganti server. Nanging ora, sawise udakara 10 jam uga tiba.
Kahanan kasebut bola-bali nganti pirang-pirang dina. Server bisa digunakake, tubrukan sawise udakara 10 jam lan ora diwiwiti sajrone 2 jam sabanjure. Padha mriksa cooling, bocor memori, padha mriksa kabeh, nanging ora ketemu apa-apa. Banjur tabrakan mandheg.
Seminggu liwat tanpa beban... kabeh pada seneng. Seneng nganti kabeh diwiwiti maneh. Gambare padha. 10 jam kerja, 2-3 jam istirahat ...
Banjur ana wong (aku rumangsa ngandhani yen wong iki ora ana hubungane karo IT) ujar:
"Iki ombak!"
Panguwuh kasebut ditemoni kanthi tatapan kosong, lan tangane sapa wae sing ragu-ragu ing tombol telpon keamanan.
"Iku mandheg nggarap ombak."
Iki bakal katon minangka konsep sing manca kanggo para pekerja dhukungan IT, sing ora bisa maca Tide Yearbook nalika lungguh kanggo ngombe kopi. Padha diterangno sing iki ora bisa related kanggo pasang ing sembarang cara, amarga server wis digunakake kanggo minggu tanpa gagal.
"Minggu kepungkur pasang surut, nanging minggu iki dhuwur."
A terminologi sethitik kanggo wong-wong sing ora duwe lisensi yacht. Ombak gumantung ing siklus rembulan. Lan nalika Bumi muter, saben 12,5 jam tarikan gravitasi Srengenge lan Bulan nggawe gelombang pasang. Ing wiwitan siklus 12,5 jam ana pasang dhuwur, ing tengah siklus ana pasang surut, lan ing pungkasan ana pasang dhuwur maneh. Nanging nalika orbit rembulan owah, mula bedane pasang surut lan pasang surut. Nalika Bulan ana ing antarane Srengenge lan Bumi utawa ing sisih ngelawan Bumi (rembulan utawa ora ana rembulan), kita entuk pasang Syzygyn - pasang dhuwur paling dhuwur lan pasang surut paling rendah. Ing setengah rembulan kita entuk pasang quadrature - pasang paling ngisor. Bentenipun antarane loro extremes sudo nemen. Siklus rembulan suwene 28 dina: syzygian - quadrature - syzygian - quadrature.
Nalika teknisi diterangake babagan inti saka pasukan pasang surut, dheweke langsung mikir yen kudu nelpon polisi. Lan cukup logis. Nanging pranyata wong lanang iku bener. Rong minggu sakdurunge, ana kapal perusak ditambat ora adoh saka kantor. Saben-saben ombak munggah menyang dhuwur tartamtu, pos radar kapal rampung ing tingkat lantai kamar server. Lan radar (utawa peralatan perang elektronik, utawa sawetara dolanan militer liyane) nggawe kekacauan ing komputer.
Misi penerbangan kanggo roket
Aku ditugasi porting gedhe (kira-kira 400 ewu baris) kontrol peluncuran roket lan sistem ngawasi kanggo versi anyar saka sistem operasi, compiler lan basa. Luwih tepate, saka Solaris 2.5.1 nganti Solaris 7, lan saka Verdix Ada Development System (VADS), ditulis ing Ada 83, menyang sistem Rational Apex Ada, ditulis ing Ada 95. VADS dituku dening Rational, lan produke yaiku lungse, sanajan Nyoto nyoba kanggo ngleksanakake versi kompatibel paket VADS-tartamtu kanggo ease transisi menyang Apex compiler.
Telung wong nulungi aku mung njaluk kode sing disusun kanthi resik. Butuh rong minggu. Banjur aku kerja dhewe kanggo nggawe sistem kasebut. Ing cendhak, iku arsitektur paling awon lan implementasine saka sistem software aku wis ketemu, supaya njupuk liyane rong sasi kanggo ngrampungake port. Sistem kasebut banjur diajukake kanggo uji coba, sing butuh sawetara wulan maneh. Aku langsung mbenerake kewan omo sing ditemokake sajrone tes, nanging jumlahe cepet suda (kode sumber minangka sistem produksi, saengga fungsine bisa dipercaya, aku mung kudu mbusak bug sing muncul nalika adaptasi menyang kompiler anyar). Pungkasane, nalika kabeh wis bisa digunakake, aku ditransfer menyang proyek liyane.
Lan ing dina Jumuah sadurunge Thanksgiving, telpon muni.
Peluncuran roket kasebut kudu diuji kira-kira telung minggu, lan sajrone tes laboratorium countdown, urutan perintah diblokir. Ing urip nyata, iki bakal mbatalake test, lan yen blockage dumadi ing sawetara detik miwiti engine, sawetara tumindak ora bisa dibalèkaké bakal kelakon ing sistem tambahan, kang mbutuhake dawa - lan larang - kesiapan roket. Ora bakal diwiwiti, nanging akeh wong sing bakal kesel banget amarga kelangan wektu lan akeh dhuwit. Aja nganti ana wong sing ngandhani yen Departemen Pertahanan mbuwang dhuwit kanthi sembrono-aku durung tau ketemu manajer kontrak sing ora ngetrapake anggaran dhisik utawa kaping pindho, disusul jadwal.
Ing sasi sadurunge, tantangan countdown iki wis atusan kaping ing akeh variasi, karo mung sawetara hiccups cilik. Dadi kemungkinan kedadeyan kasebut sithik banget, nanging akibate pancen signifikan. Multiply loro faktor iki, lan sampeyan bakal ngerti sing warta mbadek minggu liburan rusak kanggo kula lan Welasan engineers lan Managers.
Lan manungsa waé wis mbayar kanggo kula minangka wong sing njejeri sistem.
Kaya umume sistem kritis keamanan, akeh paramèter sing dicathet, saéngga cukup gampang kanggo ngenali sawetara baris kode sing dieksekusi sadurunge sistem nabrak. Lan mesthi, ora ana sing ora biasa; ekspresi sing padha wis sukses dieksekusi sacara harfiah kaping pirang-pirang sajrone wektu sing padha.
Kita diarani wong saka Apex menyang Rasional amarga dheweke sing ngembangake kompiler lan sawetara rutinitas sing dikembangake diarani kode sing curiga. Padha (lan wong liya) kesengsem sing ana perlu kanggo njaluk menyang ROOT saka masalah secara harfiah wigati nasional.
Amarga ora ana sing menarik ing jurnal kasebut, kita mutusake nyoba ngasilake masalah kasebut ing laboratorium lokal. Iki dudu tugas sing gampang amarga acara kasebut kedadeyan kira-kira sapisan saben 1000 mlaku. Salah sawijining alesan sing dicurigai yaiku telpon menyang fungsi mutex sing dikembangake vendor (bagean saka paket migrasi VADS) Unlock ora mimpin kanggo mbukak kunci. Utas pangolahan sing diarani fungsi ngolah pesen deg-degan, sing biasane teka saben detik. Kita ngunggahake frekuensi dadi 10 Hz, yaiku 10 kali per detik, lan wiwit mlaku. Kira-kira jam mengko sistem dikunci dhewe. Ing log, kita weruh yen urutan pesen sing direkam padha karo nalika tes gagal. We digawe sawetara liyane roto, sistem iki terus-terusan diblokir 45-90 menit sawise wiwitan, lan saben wektu log ngemot rute padha. Sanajan sacara teknis kita nindakake kode sing beda - frekuensi pesen beda - prilaku sistem kasebut padha, mula kita yakin manawa skenario beban iki nyebabake masalah sing padha.
Saiki kita kudu ngerti ngendi persis pamblokiran dumadi ing urutan ekspresi.
Iki implementasine saka sistem digunakake sistem tugas Ada, lan digunakake iku luar biasa lingkungan. Tugas minangka konstruksi tingkat dhuwur sing bisa dieksekusi bebarengan ing Ada, kaya thread eksekusi, mung dibangun ing basa kasebut. Nalika rong tugas kudu komunikasi, dheweke "nyetel rendezvous", ngganti data sing dibutuhake, banjur mungkasi rendezvous lan bali menyang eksekusi independen. Nanging, sistem kasebut ditindakake kanthi beda. Sawise tugas target ketemu, tugas target rendezvoused karo tugas liyane, kang banjur rendezvoused karo tugas katelu, lan sateruse nganti sawetara pangolahan rampung. Sawise iki, kabeh rendezvous iki rampung lan saben tugas kudu bali menyang eksekusi. Sing, kita padha dealing karo sistem telpon fungsi paling larang ing donya, kang mungkasi kabeh "multitasking" proses nalika diproses bagéan saka data input. Lan sadurunge iki ora mimpin kanggo masalah mung amarga throughput banget kurang.
Aku njlèntrèhaké mekanisme tugas iki amarga nalika Rendezvous dijaluk utawa samesthine kanggo ngrampungake, "ngalih tugas" bisa kelakon. Yaiku, prosesor bisa miwiti ngolah tugas liyane sing wis siyap dieksekusi. Pranyata metu sing nalika siji tugas siyap kanggo Rendezvous karo tugas liyane, tugas temen beda bisa miwiti kaleksanan, lan pungkasanipun kontrol bali menyang rendezvous pisanan. Lan acara liyane bisa kedadeyan sing nyebabake tugas kanggo ngalih; siji acara kuwi telpon kanggo fungsi sistem, kayata printing utawa nglakokaké mutex a.
Kanggo ngerti baris kode sing nyebabake masalah, aku kudu golek cara kanggo ngrekam kemajuan liwat urutan statement tanpa micu switch tugas, sing bakal nyegah kacilakan. Dadi aku ora bisa njupuk kauntungan Put_Line()supaya ora nindakake operasi I/O. Aku bisa nyetel variabel counter utawa soko padha, nanging carane aku bisa ndeleng regane yen aku ora bisa nampilake ing layar?
Uga, nalika mriksa log, ternyata, sanajan pembekuan ing pangolahan pesen deg-degan, sing ngalangi kabeh operasi I / O saka proses kasebut lan nyegah pangolahan liyane ditindakake, tugas independen liyane terus dileksanakake. Tegese, karya kasebut ora diblokir kabeh, mung rantai tugas (kritis).
Iki minangka pitunjuk sing dibutuhake kanggo ngevaluasi ekspresi pamblokiran.
Aku nggawe paket Ada sing ngemot tugas, jinis enumerated, lan variabel global saka jinis kasebut. Literal sing bisa diwatesi diikat karo ekspresi tartamtu saka urutan masalah (contone. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), banjur dilebokake ekspresi penugasan menyang sing menehi enumerasi sing cocog karo variabel global. Wiwit kode obyek kabeh iki mung disimpen ing memori, ngoper tugas minangka asil saka eksekusi iku arang banget dipercaya. Kita utamané curiga karo ekspresi sing bisa ngalih tugas, amarga pamblokiran kasebut ditindakake nalika dieksekusi tinimbang bali nalika ngalih tugas kasebut (amarga sawetara alasan).
Tugas nelusuri mung mlaku ing daur ulang lan mriksa periodik kanggo ndeleng yen nilai variabel global wis diganti. Kanthi saben pangowahan, nilai kasebut disimpen menyang file. Banjur Enteni cendhak lan mriksa anyar. Aku nulis variabel menyang file amarga tugas dieksekusi mung nalika sistem milih kanggo eksekusi nalika ngoper tugas ing area masalah. Apa wae sing kedadeyan ing tugas iki ora bakal mengaruhi tugas liyane sing diblokir sing ora ana hubungane.
Dikarepake yen sistem tekan titik ngeksekusi kode masalah, variabel global bakal direset nalika pindhah menyang saben ekspresi sabanjure. Banjur ana kedadeyan sing nyebabake tugas kasebut ngalih, lan amarga frekuensi eksekusi (10 Hz) luwih murah tinimbang tugas ngawasi, monitor bisa nangkep nilai variabel global lan nulis. Ing kahanan normal, aku bisa njaluk urutan mbaleni saka subset enumerations: nilai pungkasan saka variabel ing wektu ngalih tugas. Nalika digantung, variabel global ora kudu diganti maneh, lan nilai pungkasan sing ditulis bakal nuduhake ekspresi sing ora rampung.
Aku mlayu kode karo nelusuri. Dheweke beku. Lan ngawasi makarya kaya clockwork.
Log kasebut ngemot urutan sing dikarepake, sing diselani karo nilai sing nuduhake yen mutex diarani Unlock, lan tugas ora rampung - kaya kasus ewonan telpon sadurunge.
Insinyur Apex kanthi ati-ati nganalisa kode kasebut ing wektu iki lan nemokake papan ing mutex ing ngendi, kanthi teori, kunci bisa kedadeyan. Nanging kemungkinan kasebut sithik banget, amarga mung urutan acara tartamtu sing kedadeyan ing wektu tartamtu bisa nyebabake pamblokiran. Hukum Murphy, wong lanang, iku Hukum Murphy.
Kanggo nglindhungi Piece saka kode aku needed, Aku ngganti telpon fungsi mutex (dibangun ing ndhuwur fungsi OS mutex) karo paket Ada mutex native cilik kanggo kontrol akses mutex menyang Piece.
Aku dilebokake menyang kode lan mbukak test. Pitung jam mengko kode isih bisa digunakake.
Kode Kula diajukake kanggo nyoto, ngendi padha nyawiji, disassembled, lan mriksa sing ora nggunakake pendekatan sing padha digunakake ing fungsi mutex masalah.
Iki review kode paling rame saka karir 🙂 Ana bab sepuluh engineers lan Managers ing kamar karo kula, liyane sepuluh wong ing telpon konferensi - lan kabeh padha nliti bab 20 baris kode.
Kode kasebut dideleng, file eksekusi anyar dirakit lan diajukake kanggo tes regresi resmi. Sawetara minggu sabanjure, tes countdown sukses lan roket kasebut mandheg.
Oke, iku kabeh apik lan apik, nanging apa gunane crita?
Iku masalah pancen njijiki. Atusan ewu baris kode, eksekusi paralel, liwat rolas pangolahan interaksi, arsitektur miskin lan implementasine miskin, antarmuka kanggo sistem ditempelake lan mayuta-yuta dolar ngginakaken. Ora tekanan, bener.
Aku ora mung siji sing nggarap masalah iki, sanajan aku ana ing sorotan nalika aku nindakake porting. Nanging sanajan aku nindakake, iku ora ateges aku ngerti kabeh atusan ewu baris kode, utawa malah skimmed wong. Kode lan log dianalisis dening insinyur ing saindenging negara, nanging nalika dheweke ngandhani hipotesis babagan penyebab kegagalan kasebut, mung butuh setengah menit kanggo mbantah. Lan nalika aku dijaluk kanggo njelasno teori, aku bakal pass menyang wong liya, amarga iku ketok kanggo kula sing engineers iki salah dalan. Swara presumptuous? Ya, iki bener, nanging aku nolak hipotesis lan panjaluk amarga alasan liyane.
Aku mangertos alam masalah. Aku ora ngerti persis ing ngendi kedadeyan kasebut utawa kenapa, nanging aku ngerti apa sing kedadeyan.
Swara taun, aku wis nglumpukake akeh kawruh lan pengalaman. Aku minangka salah sawijining pionir nggunakake Ada lan ngerti kaluwihan lan kekurangane. Aku ngerti carane perpustakaan runtime Ada nangani tugas lan menehi hasil karo eksekusi podo. Lan aku ngerti program tingkat kurang ing tingkat memori, ndhaftar lan assembler. Ing tembung liyane, aku duwe kawruh jero ing lapangan. Lan aku digunakake kanggo nemokake sabab saka masalah. Aku ora mung bisa watara bug, Aku mangertos carane nemokake iku ing lingkungan runtime banget sensitif.
Crita perjuangan karo kode kuwi ora menarik banget kanggo wong-wong sing ora ngerti fitur lan kondisi perjuangan kasebut. Nanging crita-crita kasebut mbantu kita ngerti apa sing dibutuhake kanggo ngrampungake masalah sing angel banget.
Kanggo ngatasi masalah sing angel banget, sampeyan kudu dadi luwih saka programmer. Sampeyan kudu ngerti "nasib" kode, carane sesambungan karo lingkungan, lan carane lingkungan dhewe bisa.
Banjur sampeyan bakal duwe minggu liburan rusak dhewe.
Kanggo terus.
Source: www.habr.com