ऑपरेटिंग सिस्टमची ओळख

अहो हाब्र! मी तुमच्या लक्षात आणून देऊ इच्छितो लेखांची मालिका-माझ्या मते एका मनोरंजक साहित्याचे भाषांतर - OSTEP. ही सामग्री युनिक्स सारख्या ऑपरेटिंग सिस्टीमच्या कार्याची सखोल चर्चा करते, म्हणजे, प्रक्रियांसह कार्य, विविध शेड्यूलर, मेमरी आणि आधुनिक OS बनविणारे इतर समान घटक. आपण येथे सर्व सामग्रीचे मूळ पाहू शकता येथे. कृपया लक्षात ठेवा की भाषांतर अव्यावसायिकपणे केले गेले आहे (अगदी मुक्तपणे), परंतु मला आशा आहे की मी सामान्य अर्थ राखला आहे.

या विषयावरील प्रयोगशाळेतील कार्य येथे आढळू शकते:

• मूळ
• मूळ
• माझे वैयक्तिक रुपांतर

इतर भाग:

• भाग 1: परिचय
• भाग 2: अमूर्तता: प्रक्रिया
• भाग 3: प्रक्रिया API चा परिचय
• भाग 4: शेड्युलरचा परिचय

तुम्ही माझे चॅनल येथे देखील पाहू शकता तार =)

शेड्युलरचा परिचय

समस्येचे सार: शेड्यूलर धोरण कसे विकसित करावे
अंतर्निहित शेड्युलर पॉलिसी फ्रेमवर्कची रचना कशी करावी? मुख्य गृहीतके काय असावीत? कोणते मेट्रिक्स महत्वाचे आहेत? सुरुवातीच्या संगणकीय प्रणालींमध्ये कोणती मूलभूत तंत्रे वापरली जात होती?

वर्कलोड गृहीतके

संभाव्य धोरणांवर चर्चा करण्यापूर्वी, प्रथम सिस्टीममध्ये चालणार्‍या प्रक्रियांबद्दल काही सोपी विषयांतर करूया, ज्यांना एकत्रितपणे म्हणतात. कामाचा भार. वर्कलोड परिभाषित करणे हा पॉलिसी तयार करण्याचा एक महत्त्वाचा भाग आहे आणि तुम्हाला वर्कलोडबद्दल जितके अधिक माहिती असेल तितके चांगले धोरण तुम्ही लिहू शकता.

सिस्टीममध्ये चालू असलेल्या प्रक्रियांबद्दल खालील गृहितक करूया, ज्याला कधीकधी म्हणतात रोजगार (कार्ये). यापैकी जवळजवळ सर्व गृहितके वास्तववादी नाहीत, परंतु विचारांच्या विकासासाठी आवश्यक आहेत.

1. प्रत्येक कार्य समान कालावधीसाठी चालते,
2. सर्व कार्ये एकाच वेळी सेट केली जातात,
3. नियुक्त केलेले कार्य पूर्ण होईपर्यंत कार्य करते,
4. सर्व कार्ये फक्त CPU वापरतात,
5. प्रत्येक कामाची रनिंग टाईम माहीत असते.

शेड्युलर मेट्रिक्स

लोडबद्दल काही गृहीतकांव्यतिरिक्त, भिन्न शेड्यूलिंग धोरणांची तुलना करण्यासाठी आणखी एक साधन आवश्यक आहे: शेड्यूलर मेट्रिक्स. मेट्रिक म्हणजे एखाद्या गोष्टीचे मोजमाप. शेड्युलरची तुलना करण्यासाठी अनेक मेट्रिक्स वापरल्या जाऊ शकतात.

उदाहरणार्थ, आम्ही मेट्रिक नावाचा वापर करू कार्यवाही पूर्ण (कार्यवाही पूर्ण). टास्क टर्नअराउंड टाइम हे टास्क पूर्ण होण्याची वेळ आणि सिस्टममधील टास्क अरायव्हल वेळ यांच्यातील फरक म्हणून परिभाषित केले जाते.

टर्नअराउंड=Tcompletion−Tarrival

आम्ही असे गृहीत धरले की सर्व कार्ये एकाच वेळी आली, नंतर Ta=0 आणि अशा प्रकारे Tt=Tc. जेव्हा आपण वरील गृहीतके बदलतो तेव्हा हे मूल्य स्वाभाविकपणे बदलेल.

आणखी एक मेट्रिक - सौंदर्य (निष्पक्षता, प्रामाणिकपणा). उत्पादकता आणि निष्पक्षता ही अनेकदा नियोजनातील विरोधी वैशिष्ट्ये असतात. उदाहरणार्थ, शेड्युलर कार्यप्रदर्शन ऑप्टिमाइझ करू शकतो, परंतु इतर कार्ये चालण्यासाठी प्रतीक्षा करण्याच्या किंमतीवर, त्यामुळे निष्पक्षता कमी होते.

फर्स्ट इन फर्स्ट आउट (फिफो)

सर्वात मूलभूत अल्गोरिदम जो आपण अंमलात आणू शकतो त्याला FIFO किंवा म्हणतात प्रथम ये (आत), प्रथम सेवा (बाहेर). या अल्गोरिदमचे अनेक फायदे आहेत: ते अंमलात आणणे खूप सोपे आहे आणि ते आपल्या सर्व गृहितकांना बसते आणि कार्य उत्तम प्रकारे करते.

एक साधे उदाहरण पाहू. समजा 3 कार्ये एकाच वेळी सेट केली होती. परंतु आपण असे गृहीत धरू की कार्य A हे इतर सर्वांपेक्षा थोडे आधी आले आहे, म्हणून ते इतरांपेक्षा पूर्वीच्या अंमलबजावणीच्या सूचीमध्ये दिसेल, जसे की C च्या सापेक्ष B प्रमाणे. त्यापैकी प्रत्येक 10 सेकंदांसाठी कार्यान्वित होईल असे गृहीत धरू. या प्रकरणात ही कामे पूर्ण करण्यासाठी सरासरी वेळ किती असेल?

मूल्ये मोजून - 10+20+30 आणि 3 ने भागल्यास, आम्हाला सरासरी प्रोग्राम अंमलबजावणीची वेळ 20 सेकंदांइतकी मिळते.
आता आपल्या गृहीतकात बदल करण्याचा प्रयत्न करूया. विशेषतः, गृहीतक 1 आणि अशा प्रकारे आपण यापुढे असे गृहीत धरणार नाही की प्रत्येक कार्य कार्यान्वित होण्यासाठी समान वेळ लागतो. यावेळी फिफोची कामगिरी कशी असेल?

हे दिसून येते की, वेगवेगळ्या कार्यांच्या अंमलबजावणीच्या वेळेचा FIFO अल्गोरिदमच्या उत्पादकतेवर अत्यंत नकारात्मक प्रभाव पडतो. समजू की कार्य A ला पूर्ण होण्यास 100 सेकंद लागतील, तर B आणि C ला अजून प्रत्येकी 10 सेकंद लागतील.

आकृतीवरून पाहिल्याप्रमाणे, प्रणालीसाठी सरासरी वेळ असेल (100+110+120)/3=110. या प्रभावाला म्हणतात काफिला प्रभाव, जेव्हा संसाधनाचे काही अल्प-मुदतीचे ग्राहक जड ग्राहकांच्या मागे रांगेत उभे असतात. हे किराणा दुकानातील लाईनसारखे आहे जेव्हा तुमच्यासमोर एक पूर्ण कार्ट घेऊन ग्राहक असतो. समस्येचे सर्वोत्तम उपाय म्हणजे रोख नोंदणी बदलण्याचा प्रयत्न करणे किंवा आराम करणे आणि खोल श्वास घेणे.

सर्वात लहान नोकरी प्रथम

हेवीवेट प्रक्रियेसह अशीच परिस्थिती कशी तरी सोडवणे शक्य आहे का? नक्कीच. नियोजनाचा दुसरा प्रकार म्हणतातसर्वात लहान नोकरी प्रथम (SJF). त्याचे अल्गोरिदम देखील अगदी आदिम आहे - नावाप्रमाणेच, सर्वात लहान कार्ये प्रथम, एकामागून एक सुरू केली जातील.

या उदाहरणात, समान प्रक्रिया चालवण्याचा परिणाम म्हणजे सरासरी प्रोग्राम टर्नअराउंड वेळेत सुधारणा होईल आणि ते समान असेल 50 ऐवजी 110, जे जवळजवळ 2 पट चांगले आहे.

अशा प्रकारे, सर्व कार्ये एकाच वेळी येतात या गृहीतकासाठी, SJF अल्गोरिदम हा सर्वात अनुकूल अल्गोरिदम असल्याचे दिसते. तथापि, आमचे गृहितक अजूनही वास्तववादी वाटत नाहीत. यावेळी आपण गृहीतक 2 बदलतो आणि यावेळी कल्पना करा की कार्ये कोणत्याही वेळी उपस्थित असू शकतात आणि सर्व एकाच वेळी नाही. यामुळे कोणत्या समस्या उद्भवू शकतात?

चला कल्पना करूया की टास्क A (100c) प्रथम येते आणि कार्यान्वित करणे सुरू होते. t=10 वाजता, B आणि C कार्ये येतात, ज्यापैकी प्रत्येकाला 10 सेकंद लागतील. तर सरासरी अंमलबजावणी वेळ (100+(110-10)+(120-10))3 = 103 आहे. हे सुधारण्यासाठी शेड्युलर काय करू शकतो?

प्रथम पूर्ण करण्यासाठी सर्वात कमी वेळ (STCF)

परिस्थिती सुधारण्यासाठी, आम्ही गृहितक 3 वगळतो की प्रोग्राम लॉन्च झाला आहे आणि पूर्ण होईपर्यंत चालतो. याव्यतिरिक्त, आम्हाला हार्डवेअर समर्थनाची आवश्यकता असेल आणि, जसे आपण अंदाज लावू शकता, आम्ही वापरू टाइमर चालू असलेल्या कार्यात व्यत्यय आणणे आणि संदर्भ स्विचिंग. अशाप्रकारे, शेड्युलर टास्क B, C येण्याच्या क्षणी काहीतरी करू शकतो - कार्य A कार्यान्वित करणे थांबवू शकतो आणि B आणि C कार्ये प्रक्रियेत ठेवू शकतो आणि ते पूर्ण झाल्यानंतर, प्रक्रिया A कार्यान्वित करणे सुरू ठेवू शकतो. अशा शेड्युलरला म्हणतात. STCFकिंवा प्रीएम्प्टिव्ह जॉब प्रथम.

या प्लॅनरचा परिणाम पुढील परिणाम असेल: ((120-0)+(20-10)+(30-10))/3=50. अशा प्रकारे, असा शेड्यूलर आमच्या कार्यांसाठी अधिक इष्टतम बनतो.

मेट्रिक प्रतिसाद वेळ

अशाप्रकारे, जर आपल्याला कार्ये चालवण्याची वेळ माहित असेल आणि ही कार्ये फक्त CPU वापरत असतील तर STCF हा सर्वोत्तम उपाय असेल. आणि एकदा सुरुवातीच्या काळात, हे अल्गोरिदम चांगले काम करत होते. तथापि, वापरकर्ता आता तिचा बहुतेक वेळ टर्मिनलवर घालवतो आणि उत्पादक परस्परसंवादी अनुभवाची अपेक्षा करतो. अशा प्रकारे नवीन मेट्रिकचा जन्म झाला - प्रतिसाद वेळ (प्रतिसाद).

प्रतिसाद वेळ खालीलप्रमाणे मोजला जातो:

Tresponse=Tfirstrun−Tarrival

अशा प्रकारे, मागील उदाहरणासाठी, प्रतिसाद वेळ असेल: A=0, B=0, C=10 (abg=3,33).

आणि असे दिसून आले की एकाच वेळी 3 कार्ये येतात अशा परिस्थितीत एसटीसीएफ अल्गोरिदम इतका चांगला नाही - लहान कार्ये पूर्णपणे पूर्ण होईपर्यंत प्रतीक्षा करावी लागेल. त्यामुळे टर्नअराउंड टाइम मेट्रिकसाठी अल्गोरिदम चांगला आहे, परंतु इंटरॅक्टिव्हिटी मेट्रिकसाठी वाईट आहे. कल्पना करा की तुम्ही टर्मिनलवर बसून एडिटरमध्ये अक्षरे टाइप करण्याचा प्रयत्न करत आहात आणि 10 सेकंदांपेक्षा जास्त प्रतीक्षा करावी लागली आहे कारण इतर काही कार्य CPU हाती घेत आहे. हे फार आनंददायी नाही.

त्यामुळे आम्हाला आणखी एका समस्येचा सामना करावा लागतो - प्रतिसाद वेळेसाठी संवेदनशील असलेले शेड्युलर कसे तयार करावे?

गोल रॉबिन

या समस्येचे निराकरण करण्यासाठी एक अल्गोरिदम विकसित केला गेला गोल रॉबिन (आरआर). मूळ कल्पना अगदी सोपी आहे: कार्ये पूर्ण होईपर्यंत चालवण्याऐवजी, आम्ही विशिष्ट कालावधीसाठी कार्य चालवू (ज्याला टाइम स्लाइस म्हणतात) आणि नंतर रांगेतून दुसर्‍या कार्यावर स्विच करू. सर्व कार्ये पूर्ण होईपर्यंत अल्गोरिदम त्याच्या कार्याची पुनरावृत्ती करतो. या प्रकरणात, प्रोग्रामचा रनिंग टाईम वेळेच्या गुणाकार असणे आवश्यक आहे ज्यानंतर टाइमर प्रक्रियेत व्यत्यय आणेल. उदाहरणार्थ, जर टाइमर प्रत्येक x=10ms प्रक्रियेत व्यत्यय आणत असेल, तर प्रक्रिया अंमलबजावणी विंडोचा आकार 10 च्या पटीत असावा आणि 10,20 किंवा x*10 असावा.

चला एक उदाहरण पाहू: एबीसी कार्य एकाच वेळी सिस्टममध्ये येतात आणि त्यापैकी प्रत्येकाला 5 सेकंद चालवायचे आहेत. SJF अल्गोरिदम दुसरे कार्य सुरू करण्यापूर्वी प्रत्येक कार्य पूर्ण करेल. याउलट, लॉन्च विंडो = 1s सह RR अल्गोरिदम खालीलप्रमाणे कार्ये पार करेल (चित्र 4.3):

(SJF पुन्हा (प्रतिसाद वेळेसाठी वाईट)

(राउंड रॉबिन (प्रतिसाद वेळेसाठी चांगले)

RR अल्गोरिदमसाठी सरासरी प्रतिसाद वेळ (0+1+2)/3=1 आहे, तर SJF (0+5+10)/3=5.

RR साठी टाइम विंडो हा एक अतिशय महत्त्वाचा पॅरामीटर आहे असे मानणे तर्कसंगत आहे; ते जितके लहान असेल तितका प्रतिसाद वेळ जास्त असेल. तथापि, तुम्ही ते खूप लहान करू नये, कारण संदर्भ बदलण्याची वेळ देखील एकूण कामगिरीमध्ये भूमिका बजावेल. अशा प्रकारे, अंमलबजावणी विंडो वेळेची निवड OS आर्किटेक्टद्वारे सेट केली जाते आणि त्यामध्ये कार्यान्वित करण्याच्या नियोजित कार्यांवर अवलंबून असते. संदर्भ बदलणे हे एकमेव सेवा ऑपरेशन नाही जे वेळ वाया घालवते - रनिंग प्रोग्राम इतर बर्‍याच गोष्टींवर कार्य करतो, उदाहरणार्थ, विविध कॅशे आणि प्रत्येक स्विचसह हे वातावरण जतन करणे आणि पुनर्संचयित करणे आवश्यक आहे, ज्यासाठी बरेच काही लागू शकते. वेळ

जर आपण फक्त प्रतिसाद वेळ मेट्रिकबद्दल बोलत असाल तर RR हा एक उत्तम शेड्युलर आहे. परंतु या अल्गोरिदमसह टास्क टर्नअराउंड टाइम मेट्रिक कसे वागेल? वरील उदाहरणाचा विचार करा, जेव्हा A, B, C = 5s ची ऑपरेटिंग वेळ आणि त्याच वेळी आगमन होते. टास्क A 13 वाजता, B 14 वाजता, C 15 वाजता संपेल आणि सरासरी टर्नअराउंड वेळ 14 सेकंद असेल. अशा प्रकारे, टर्नओव्हर मेट्रिकसाठी RR हा सर्वात वाईट अल्गोरिदम आहे.

अधिक सामान्य शब्दात, कोणतेही RR-प्रकार अल्गोरिदम योग्य आहे; ते CPU वेळ सर्व प्रक्रियांमध्ये समान रीतीने विभाजित करते. आणि अशा प्रकारे, हे मेट्रिक्स सतत एकमेकांशी संघर्ष करतात.

अशा प्रकारे, आमच्याकडे अनेक विरोधाभासी अल्गोरिदम आहेत आणि त्याच वेळी अजूनही अनेक गृहितके शिल्लक आहेत - की कार्य वेळ ज्ञात आहे आणि कार्य फक्त CPU वापरते.

I/O सह मिसळणे

सर्व प्रथम, प्रक्रिया केवळ CPU वापरते असे गृहितक 4 काढून टाकूया; नैसर्गिकरित्या, असे नाही आणि प्रक्रिया इतर उपकरणांमध्ये प्रवेश करू शकतात.

ज्या क्षणी कोणतीही प्रक्रिया I/O ऑपरेशनची विनंती करते, प्रक्रिया I/O पूर्ण होण्याची प्रतीक्षा करत अवरोधित स्थितीत प्रवेश करते. जर I/O हार्ड ड्राइव्हवर पाठवले असेल, तर अशा ऑपरेशनला अनेक एमएस किंवा जास्त वेळ लागू शकतो आणि प्रोसेसर या क्षणी निष्क्रिय असेल. या वेळी, शेड्यूलर इतर कोणत्याही प्रक्रियेसह प्रोसेसर व्यापू शकतो. शेड्युलरला पुढील निर्णय घ्यावा लागेल जेव्हा प्रक्रिया पूर्ण होईल. असे झाल्यावर, एक व्यत्यय येईल आणि OS I/O नावाची प्रक्रिया तयार स्थितीत ठेवेल.

चला अनेक समस्यांचे उदाहरण पाहू. त्यांच्यापैकी प्रत्येकाला 50ms CPU वेळ आवश्यक आहे. तथापि, प्रथम प्रत्येक 10ms मध्ये I/O ऍक्सेस करेल (जे दर 10ms नंतर कार्यान्वित केले जाईल). आणि प्रक्रिया B फक्त I/O शिवाय 50ms प्रोसेसर वापरते.

या उदाहरणात आपण STCF शेड्युलर वापरू. A सारखी प्रक्रिया सुरू केल्यास शेड्युलर कसे वागेल? तो पुढील गोष्टी करेल: प्रथम तो A प्रक्रिया पूर्ण करेल आणि नंतर B प्रक्रिया करेल.

या समस्येचे निराकरण करण्याचा पारंपारिक दृष्टीकोन म्हणजे प्रक्रिया A च्या प्रत्येक 10 ms सबटास्कला स्वतंत्र कार्य म्हणून हाताळणे. अशा प्रकारे, STJF अल्गोरिदमसह प्रारंभ करताना, 50 ms टास्क आणि 10 ms टास्कमधील निवड स्पष्ट आहे. नंतर, सबटास्क A पूर्ण झाल्यावर, प्रक्रिया B आणि I/O लाँच होईल. I/O पूर्ण झाल्यानंतर, प्रक्रिया B ऐवजी 10ms प्रक्रिया A पुन्हा सुरू करण्याची प्रथा असेल. अशाप्रकारे, ओव्हरलॅप लागू करणे शक्य आहे, जेथे CPU दुसर्‍या प्रक्रियेद्वारे वापरला जातो आणि पहिल्या प्रक्रियेची वाट पाहत असतो. I/O आणि परिणामी, प्रणालीचा अधिक चांगला उपयोग केला जातो - ज्या क्षणी परस्परसंवादी प्रक्रिया I/O ची वाट पाहत असतात, इतर प्रक्रिया प्रोसेसरवर चालवल्या जाऊ शकतात.

ओरॅकल आता नाही

आता कार्याची रनिंग टाईम माहीत आहे या गृहीतकापासून मुक्त होण्याचा प्रयत्न करूया. संपूर्ण यादीतील हे सर्वसाधारणपणे सर्वात वाईट आणि सर्वात अवास्तव गृहितक आहे. खरं तर, सरासरी सामान्य OS मध्ये, OS ला सहसा कार्यांच्या अंमलबजावणीच्या वेळेबद्दल फारच कमी माहिती असते, तर मग कार्य पूर्ण करण्यासाठी किती वेळ लागेल हे जाणून घेतल्याशिवाय तुम्ही शेड्यूलर कसे तयार करू शकता? कदाचित आम्ही या समस्येचे निराकरण करण्यासाठी काही आरआर तत्त्वे वापरू शकतो?

परिणाम

आम्ही टास्क शेड्युलिंगच्या मूलभूत कल्पना पाहिल्या आणि शेड्युलरच्या 2 कुटुंबांकडे पाहिले. पहिले पहिले सर्वात लहान टास्क सुरू करते आणि त्यामुळे टर्नअराउंड टाइम वाढतो, तर दुसरा सर्व टास्कमध्ये समान रीतीने फाटतो, प्रतिसाद वेळ वाढवतो. दोन्ही अल्गोरिदम खराब आहेत जेथे इतर कुटुंबाचे अल्गोरिदम चांगले आहेत. आम्ही CPU आणि I/O चा समांतर वापर कार्यप्रदर्शन कसे सुधारू शकतो हे देखील पाहिले, परंतु OS दावेदारीसह समस्या सोडवली नाही. आणि पुढील धड्यात आपण एका नियोजकाकडे पाहू जो तात्काळ भूतकाळात डोकावतो आणि भविष्याचा अंदाज लावण्याचा प्रयत्न करतो. आणि त्याला बहु-स्तरीय फीडबॅक रांग म्हणतात.

स्त्रोत: www.habr.com