ասում ա՝ ուզում էինք պարալելլիզացնել, արդիւնքում՝ պարալիզացրինք։
#ծրագրաւորում #տէք #զուգահեռութիւն
իւնիքս պրոցեսները ունենում են վիճակ։ օրինակ, կարող են լինել կանգնեցուած, կամ տուեալ պահին գործող։ կարող են լինել վրիպազէրծուող։
իսկ կարող են ունենալ պրոցեսների աղիւսակի մէջ որպէս D նշուած վիճակ, որի մասին ձեռնարկում ասւում ա՝ uninterraptible I/O wait։
ու uninterraptible ա այն բառացիօրէն՝ այն չի լինում ընդհատել։
հարցն այն ա, որ պրոցեսը՝ որը ծրագիր ա կատարման ընթացքում, անում ա տարբեր գործողութիւններ՝ օրինակ ինչ֊որ տուեալներ ա ստանում եւ մշակում։ մշակելու ալգորիթմը ձեւակերպում ա ծրագրաւորողը, իսկ ինչպէ՞ս ա տուեալներ ստանում՝ օրինակ դիսկից, կամ համացանցից։
դիսկից կամ համացանցից կարդալ ամէն ծրագիրը չպիտի կարողանայ՝ էդ օհ֊ի պարտականութիւնն ա՝ դիսկից մի բան կարդալ ու տալ ծրագրին։
այդ պատճառով ծրագիրը կանչում ա, դիցուք read() օհ֊ի API֊ի կանչ, ու երբ այն կանչում ա այդ ֆունկցիան, բնական ա, պիտի սպասի, մինչեւ օհ֊ը կարդայ, դիցուք մի բայթ, դիսկի որեւէ ֆայլից, ու տայ ծրագրին։ այս պահին արդէն ծրագիրը գործ չի անում՝ անում ա գործ կերնելը՝ միջուկը։
զի ժամանակակից օպերացիոն համակարգերը պետութեան կամ լուրջ կազմակերպութեան պէս են՝ ծրագիրը չի կարող ցանկացած ռեսուրսի դիմել, ինչպէս ընկերութեան աշխատողը չի կարող տեսնել HR֊ի կամ հաշուապահութեան տուեալները, իսկ ոստիկանութեան աշխատողը չի կարող առանց հատուկ հայցի դիմել փողոցային խցիկներից տուեալներ ստանալու համար։
այսպէս, DOS֊ի ծրագիրը փաստացի կարող էր օգտագործել համակարգի բոլոր հնարաւոր ռեսուրսները։ դա ծրագրին սովորաբար сходило с рук/it could get away with it հաջողւում էր առանց շատ խնդիրների, շնորհիւ նրա, որ այն միակ կատարուող ծրագիրն էր։
աւելի բեթար բարդ վիճակ էր windows95֊ոտ համակարգերում, ուր եւ ակտուալ էին BSOD֊ն ու viral դարձան վիրուսները։
բայց եւ աւելի հին, Unix համակարգերում, նման հարցերը վաղուց ինչ֊որ ձեւ լուծուած էին եւ էդ լուծումները դարձան մէյնսթրիմ այսօր (այլ հարց ա որ դրանք լուծելու այլ ժամանակակից տեսակէտներ կան)։
էսօր սովորական լուծումն այն ա, որ ծրագիրը չի կարող օգտագործել որեւէ ռեսուրս առանց օհ֊ի թոյլտւութեան, զի բոլոր ռեսուրսները՝ ֆայլերը, յիշողութիւնը, նկարչութիւնը (վիդեօ յիշողութիւնը), ցանցը՝ տրամադրում ա միջուկը, հաւանութիւն տալով ծրագրի հայտին, կամ մերժում ա, չի տրամադրում՝ համարելով որ այդ պրոցեսը (որն աշխատում այդ օգտատիրոջ անունից) չի կարող դիմել ռեսուրսի համար, կամ որ աւել ռեսուրս իրան չի հասնում՝ չափազանց շատ ա արդէն օգտագործել, եւ այլն։
այսպէս, նիշքից կարդալու համար, նախ պէտք ա օհ֊ին խնդրել այդ նիշքը տրամադրել, իսկ երբ այն թոյլ տայ՝ օկ, բացիր նիշքը, պիտի ամէն անգամ խնդրես օհ֊ին որ կարդայ, ու քեզ ասի ինչ ա մէջը գրուած։ ինքնուրոյն քիթդ խոթել դրա մէջ չես կարող՝ ամէնն արւում ա օհ֊ի միջոցով։
(windows֊ի աշխարհում դա սկսուեց windows nt֊ից, որն աւելի մասնագիտական, ոչ մէյնսթրիմ մայքրոսոֆթի օհ էր։։ իննսունականներին nt օգտագործող ծրագրաւորողները հպարտանում էին որ իրենց կարգիչներն անհամեմատ աւելի անխոցելի էին զանազան վիրուսների հանդէպ, իսկ windows 2000֊ից նոյն մօտեցումը կիրառուեց աւելի մէյնսթրիմ՝ ոչ միայն մասնագէտների համար։ իսկապէս, win{95,98} ընտանիքի օհ֊ի համար վիրուս գրելն առանձնապէս բարդ չէր՝ արա ինչ ուզում ես, ոչ ոք ձեռքերիդ չի խփի։ nt ընտանիքի օհ֊երի համար վիրուս գրելն արդէն էդքան տրիւիալ գործ չէր, բայց ինչպէս տեսնում ենք մինչ այսօր՝ լրիւ իրատեսական։)
հիմա հասանք այն պահին, որ խնդրում ենք օհ֊ից կարդալ բայթ՝ նիշքից։ ասացինք՝ read(), մեր ծրագիրն էս պահին այլեւս սպասում ա։ եթէ սպասելը երկար ա՝ դուք դա նկատում էք՝ ինտերֆէյսը սառում ա, երբ ծրագրաւորողը multithreaded ձեւով չի գրում։ սկսում էք կտացնել տարբեր տեղեր, եւ գիտէք, ձեր կտոցները պահւում են հատուկ բուֆերի մէջ, որը կոչւում ա message queue, որ յետոյ, երբ ծրագիրն վերսկսի աշխատանքը, էդ ձեր message֊ները պրոցես անի։
արեցինք read() ու այս պահին արդէն գնդակը միջուկի դաշտում ա, պիտի սպասենք մինչեւ մի բան վերադարձնի։ իսկ ի՞նչ անի էդ խեղճ միջուկը, եթէ էս պահին ֆայլը հասանելի չի՝ օրինակ դիսկն ա վատացել, ու չի պատասխանում, կամ դիսկը հեռավար ա, ու կապն ա անջատուել, եւ նիշքը չի երեւում։ կամ ցանցային այլ ռեսուրսից ենք օգտւում, ինտերնետ սոքեթից ենք բան կարդում։
էս էն պահն ա, երբ պրոցեսն ընդունում ա uninterraptible I/O wait կարգավիճակ։ ինչի՞ ա uninterraptible՝ հարցն այն ա, որ էդ պրոցեսը սպանել չի լինի, զի միջուկի ներսի կարդացող պրոցեսը, ըստ միջուկի ծրագրաւորողների սպանել չի կարելի։ այդ դէպքում՝ միջուկի պրոցեսի ընդհատումը կը բերի միջուկի յիշողութեան անկանխատեսելի վիճակին, որը կարող ա բերել ընդհանուր օպերացիոն համակարգի անկանխատեսելի վիճակին։ եւ միջուկի նախագծողները համարեցին (բնականաբար) որ աւելի լաւ ա թոյլ չտալ որոշ պրոցեսներ ընդհատել, կամ այդ ընդհատումը կարող ա բերել այն աղէտալի վիճակի, որ աւելի լաւ ա մարդը, եթէ իրան իսկապէս պէտք ա՝ կոճակը սեղմելով կարգիչը վերամեկնարկի։
ինչի՞ կոճակը սեղմելով՝ զի միջուկը ինքը չի կարող ազատուել, հիմնականում, այդ իր միջի չարաբաստիկ պրոցեսից՝ զի միջուկը չի կարող շարունակել նորմալ աշխատանք եթէ ընթերցող պրոցեսն ընդհատի։
հետեւաբար նման համակարգ չի էլ լինի հրամանով(shutdown, poweroff, halt) անջատել։
իրականում ֆուտբոլը կարող ա իսկապէս լինել լաւ մետաֆորա՝ պատկերացրէք, գնդակը միջուկի՝ այլ թիմի խաղացողների մօտ ա։ պիտի հետը մի բան անեն, նոր տշեն քեզ հետ։ եթէ ընդհատես սպասելդ, ասես՝ չէ, գնդակը պիտի հէնց հիմա յայտնուի ինձ մօտ, ապա էն խաղացողները, որ գնդակ էին տշում, կարող ա իրար խփեն, ընկնեն, վնասուեն՝ անկանխատեսելի ձեւով։ եւ տէնց վնասուած օհ ունենալ աւելի վտանգաւոր ա, քան կախած պրոցես։ այլընտրանքը՝ ձեռքով կոճակ սեղմելն՝ աւելի անվտանգ ա։
ծրագրաւորման ու տտ աշխարհի հետ, իրականում շատ լաւ բռնում են իրական կեանքի, կամ գրքերի սցենարները։ պատկերացրէք, գիքորը բերում ա սամովարը դնի տիրոջ սեղանին, զի պիտի սցենարով առաջնորդուի, բայց պարզւում ա՝ սեղան չկայ, սամովարի միջի տաք ջուրը թափւում ա՝ բոլորն այրուածքներ են ստանում։ ահա ձեզ զուգահեռ ծրագրաւորման օրինակ։
դէ մինչ։
#ծրագրաւորում #տեքնոլոգիաներ #գիքոր #սամովար #զուգահեռութիւն #միջուկ #կերնել #իւնիքս #օպերացիոն_համակարգեր #օհ #ծրագրակազմ
շատ հետաքրքիր թուղթ եմ կարդում, այն մասին ինչպէս Ա2 համակարգի միջուկը փոխել են, որ այն աշխատի կոոպերատիւ մալտիթասկինգով։ սակայն դեռ լաւ չեմ հասկանում, թէ արդեօք Ա2֊ի միջուկը հիմա այդ նոր միջուն է ու արդեօք այն հիմա դարձել է «լոք ֆրի» համակարգ թէ ոչ։
#Ա2 #օբերոն #զուգահեռութիւն #ակտիւ_օբերոն #ծրագրաւորում #օպերացիոն_համակարգեր #ծրագրաւորում #թուղթ
