অপারেটিং সিস্টেমের পরিচিতি

হে হাবর! আমি আপনার নজরে আনতে চাই নিবন্ধগুলির একটি সিরিজ-আমার মতে একটি আকর্ষণীয় সাহিত্যের অনুবাদ - OSTEP। এই উপাদানটি ইউনিক্স-এর মতো অপারেটিং সিস্টেমের কাজ সম্পর্কে গভীরভাবে আলোচনা করে, যেমন, প্রক্রিয়া, বিভিন্ন সময়সূচী, মেমরি এবং অন্যান্য অনুরূপ উপাদানগুলির সাথে কাজ যা একটি আধুনিক OS তৈরি করে। আপনি এখানে সমস্ত উপকরণের আসল দেখতে পারেন এখানে. অনুগ্রহ করে মনে রাখবেন অনুবাদটি পেশাগতভাবে করা হয়েছে (বেশ অবাধে), তবে আমি আশা করি আমি সাধারণ অর্থ ধরে রেখেছি।

এই বিষয়ে ল্যাবের কাজ এখানে পাওয়া যাবে:

• оригинал
• оригинал
• আমার ব্যক্তিগত অভিযোজন

অন্য অংশ গুলো:

• অংশ 1: ​​ভূমিকা
• পার্ট 2: বিমূর্ততা: প্রক্রিয়া
• পার্ট 3: প্রসেস API এর পরিচিতি
• পার্ট 4: সিডিউলারের পরিচিতি

এছাড়াও আপনি আমার চ্যানেল চেক আউট করতে পারেন টেলিগ্রাম =)

শিডিউলারের পরিচিতি

সমস্যার সারমর্ম: কিভাবে একটি সময়সূচী নীতি বিকাশ করতে হয়
কিভাবে অন্তর্নিহিত সময়সূচী নীতি কাঠামো ডিজাইন করা উচিত? মূল অনুমান কি হওয়া উচিত? কি মেট্রিক্স গুরুত্বপূর্ণ? প্রাথমিক কম্পিউটিং সিস্টেমে কোন মৌলিক কৌশল ব্যবহার করা হয়েছিল?

কাজের চাপ অনুমান

সম্ভাব্য নীতিগুলি নিয়ে আলোচনা করার আগে, আসুন প্রথমে সিস্টেমে চলমান প্রক্রিয়াগুলি সম্পর্কে কয়েকটি সরলীকরণমূলক ডিগ্রেশন করি, যেগুলিকে সম্মিলিতভাবে বলা হয় কাজের চাপ. কাজের চাপ সংজ্ঞায়িত করা নীতি নির্মাণের একটি গুরুত্বপূর্ণ অংশ, এবং কাজের চাপ সম্পর্কে আপনি যত বেশি জানবেন, তত ভাল নীতি আপনি লিখতে পারবেন।

আসুন সিস্টেমে চলমান প্রক্রিয়াগুলি সম্পর্কে নিম্নলিখিত অনুমান করা যাক, কখনও কখনও এটিও বলা হয় কাজ (কাজ). এই অনুমানগুলির প্রায় সবই বাস্তবসম্মত নয়, তবে চিন্তার বিকাশের জন্য প্রয়োজনীয়।

1. প্রতিটি কাজ একই সময়ের জন্য চলে,
2. সমস্ত কাজ একযোগে সেট করা হয়,
3. অর্পিত কাজটি শেষ না হওয়া পর্যন্ত কাজ করে,
4. সমস্ত কাজ শুধুমাত্র CPU ব্যবহার করে,
5. প্রতিটি কাজের চলমান সময় জানা যায়।

শিডিউলার মেট্রিক্স

লোড সম্পর্কে কিছু অনুমান ছাড়াও, বিভিন্ন সময়সূচী নীতির তুলনা করার জন্য আরেকটি টুল প্রয়োজন: সময়সূচী মেট্রিক্স। একটি মেট্রিক কিছু কিছু পরিমাপ মাত্র. সময়সূচী তুলনা করতে ব্যবহার করা যেতে পারে যে মেট্রিক একটি সংখ্যা আছে.

উদাহরণস্বরূপ, আমরা একটি মেট্রিক নামক ব্যবহার করব পরিবর্তনের সময় (পরিবর্তন সময়)। টাস্ক টার্নঅ্যারাউন্ড সময়কে সিস্টেমে টাস্ক সমাপ্তির সময় এবং টাস্ক আগমনের সময়ের মধ্যে পার্থক্য হিসাবে সংজ্ঞায়িত করা হয়।

Tturnaround=Tcompletion−Tarrival

যেহেতু আমরা ধরে নিয়েছি যে সমস্ত কাজ একই সময়ে এসেছে, তারপর Ta=0 এবং এইভাবে Tt=Tc। এই মান স্বাভাবিকভাবেই পরিবর্তিত হবে যখন আমরা উপরের অনুমানগুলি পরিবর্তন করি।

আরেকটি মেট্রিক - সততা (ন্যায্যতা, সততা)। উত্পাদনশীলতা এবং ন্যায্যতা প্রায়শই পরিকল্পনার বিরোধী বৈশিষ্ট্য। উদাহরণস্বরূপ, সময়সূচী কর্মক্ষমতা অপ্টিমাইজ করতে পারে, কিন্তু অন্যান্য কাজ চালানোর জন্য অপেক্ষা করার খরচে, এইভাবে ন্যায্যতা হ্রাস করে।

ফার্স্ট ইন ফার্স্ট আউট (ফিফো)

সবচেয়ে মৌলিক অ্যালগরিদম যা আমরা প্রয়োগ করতে পারি তাকে বলা হয় FIFO বা আগে আসা (ইন), প্রথম পরিবেশিত (আউট). এই অ্যালগরিদমের বেশ কয়েকটি সুবিধা রয়েছে: এটি বাস্তবায়ন করা খুব সহজ এবং এটি আমাদের সমস্ত অনুমানের সাথে খাপ খায় এবং কাজটি বেশ ভাল করে।

এর একটি সহজ উদাহরণ তাকান. ধরা যাক 3টি কাজ একই সাথে সেট করা হয়েছিল। তবে ধরে নেওয়া যাক যে টাস্ক A অন্য সকলের থেকে একটু আগে এসেছে, তাই এটি অন্যদের চেয়ে আগে এক্সিকিউশন লিস্টে উপস্থিত হবে, ঠিক যেমন B-এর সাথে C-এর আপেক্ষিক। ধরা যাক যে তাদের প্রতিটি 10 ​​সেকেন্ডের জন্য কার্যকর করা হবে। এক্ষেত্রে এসব কাজ শেষ করার গড় সময় কত হবে?

মান গণনা করে - 10+20+30 এবং 3 দ্বারা ভাগ করলে, আমরা 20 সেকেন্ডের সমান প্রোগ্রাম কার্যকর করার গড় সময় পাই।
এখন আমাদের অনুমান পরিবর্তন করার চেষ্টা করা যাক. বিশেষ করে, অনুমান 1 এবং এইভাবে আমরা আর ধরে নেব না যে প্রতিটি কাজ কার্যকর করতে একই পরিমাণ সময় নেয়। এবার ফিফো কেমন করবে?

দেখা যাচ্ছে, বিভিন্ন টাস্ক এক্সিকিউশন সময় FIFO অ্যালগরিদমের উৎপাদনশীলতার উপর অত্যন্ত নেতিবাচক প্রভাব ফেলে। ধরা যাক যে টাস্ক A-এর 100 সেকেন্ড সময় লাগবে, যখন B এবং C এখনও 10 সেকেন্ড সময় নেবে।

চিত্র থেকে দেখা যায়, সিস্টেমের গড় সময় হবে (100+110+120)/3=110। এই প্রভাব বলা হয় কাফেলার প্রভাব, যখন একটি সম্পদের কিছু স্বল্পমেয়াদী ভোক্তারা একটি ভারী ভোক্তার পরে সারিবদ্ধ হবে। এটি মুদি দোকানের লাইনের মতো যখন আপনার সামনে একটি পূর্ণ কার্ট সহ একজন গ্রাহক থাকে। সমস্যার সর্বোত্তম সমাধান হল ক্যাশ রেজিস্টার পরিবর্তন করার চেষ্টা করা বা আরাম করা এবং গভীরভাবে শ্বাস নেওয়া।

সংক্ষিপ্ততম কাজ প্রথম

হেভিওয়েট প্রক্রিয়াগুলির সাথে কি কোনওভাবে অনুরূপ পরিস্থিতি সমাধান করা সম্ভব? অবশ্যই. আরেক ধরনের পরিকল্পনা বলা হয়সংক্ষিপ্ততম কাজ প্রথম (এসজেএফ)। এর অ্যালগরিদমও বেশ আদিম - নাম থেকেই বোঝা যাচ্ছে, সংক্ষিপ্ততম কাজগুলি প্রথমে একের পর এক চালু করা হবে।

এই উদাহরণে, একই প্রক্রিয়াগুলি চালানোর ফলাফল গড় প্রোগ্রাম টার্নআরাউন্ড সময়ের একটি উন্নতি হবে এবং এটি সমান হবে 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)।

এবং দেখা যাচ্ছে যে STCF অ্যালগরিদমটি এমন একটি পরিস্থিতিতে এতটা ভাল নয় যেখানে একই সময়ে 3টি কাজ আসে - এটি ছোট কাজগুলি সম্পূর্ণরূপে সম্পূর্ণ না হওয়া পর্যন্ত অপেক্ষা করতে হবে। তাই অ্যালগরিদম টার্নআরাউন্ড টাইম মেট্রিকের জন্য ভালো, কিন্তু ইন্টারঅ্যাকটিভিটি মেট্রিকের জন্য খারাপ। কল্পনা করুন যে আপনি একটি টার্মিনালে বসে একটি সম্পাদকে অক্ষর টাইপ করার চেষ্টা করছেন এবং 10 সেকেন্ডের বেশি অপেক্ষা করতে হবে কারণ অন্য কিছু কাজ CPU গ্রহণ করছে। এটা খুব সুখকর না.

তাই আমরা আরেকটি সমস্যার সম্মুখীন হচ্ছি - কীভাবে আমরা একটি সময়সূচী তৈরি করতে পারি যা প্রতিক্রিয়া সময়ের জন্য সংবেদনশীল?

রাউন্ড রবিন

এই সমস্যা সমাধানের জন্য একটি অ্যালগরিদম তৈরি করা হয়েছিল রাউন্ড রবিন (আরআর)। মূল ধারণাটি বেশ সহজ: কাজগুলি সম্পূর্ণ না হওয়া পর্যন্ত চালানোর পরিবর্তে, আমরা একটি নির্দিষ্ট সময়ের জন্য টাস্কটি চালাব (একটি টাইম স্লাইস বলা হয়) এবং তারপর সারি থেকে অন্য টাস্কে স্যুইচ করব। সমস্ত কাজ শেষ না হওয়া পর্যন্ত অ্যালগরিদম তার কাজ পুনরাবৃত্তি করে। এই ক্ষেত্রে, প্রোগ্রামের চলমান সময় অবশ্যই সময়ের একাধিক হতে হবে যার পরে টাইমার প্রক্রিয়াটিকে বাধা দেবে। উদাহরণস্বরূপ, যদি একটি টাইমার প্রতি x=10ms একটি প্রসেসকে বাধা দেয়, তাহলে প্রসেস এক্সিকিউশন উইন্ডোর সাইজ 10 এর মাল্টিপল হওয়া উচিত এবং 10,20 বা x*10 হওয়া উচিত।

আসুন একটি উদাহরণ দেখি: ABC কাজগুলি একই সাথে সিস্টেমে আসে এবং তাদের প্রত্যেকটি 5 সেকেন্ডের জন্য চলতে চায়। SJF অ্যালগরিদম অন্য কাজ শুরু করার আগে প্রতিটি কাজ সম্পূর্ণ করবে। বিপরীতে, একটি লঞ্চ উইন্ডো = 1s সহ RR অ্যালগরিদম নিম্নলিখিত কাজগুলির মধ্য দিয়ে যাবে (চিত্র 4.3):

(SJF আবার (প্রতিক্রিয়া সময়ের জন্য খারাপ)

(রাউন্ড রবিন (প্রতিক্রিয়া সময়ের জন্য ভালো)

RR অ্যালগরিদমের গড় প্রতিক্রিয়া সময় হল (0+1+2)/3=1, যখন SJF (0+5+10)/3=5।

এটা ধরে নেওয়া যৌক্তিক যে সময় উইন্ডোটি RR-এর জন্য একটি অত্যন্ত গুরুত্বপূর্ণ প্যারামিটার; এটি যত ছোট হবে, প্রতিক্রিয়া সময় তত বেশি হবে। যাইহোক, আপনার এটিকে খুব ছোট করা উচিত নয়, যেহেতু প্রসঙ্গ পরিবর্তন করার সময়ও সামগ্রিক কর্মক্ষমতাতে ভূমিকা পালন করবে। সুতরাং, এক্সিকিউশন উইন্ডো সময়ের পছন্দটি ওএস আর্কিটেক্ট দ্বারা সেট করা হয় এবং এতে যে কাজগুলি সম্পাদন করার পরিকল্পনা করা হয়েছে তার উপর নির্ভর করে। প্রসঙ্গ স্যুইচ করা একমাত্র পরিষেবা অপারেশন নয় যা সময় নষ্ট করে - চলমান প্রোগ্রামটি অন্যান্য অনেক কিছুতে কাজ করে, উদাহরণস্বরূপ, বিভিন্ন ক্যাশে, এবং প্রতিটি সুইচের সাথে এই পরিবেশ সংরক্ষণ এবং পুনরুদ্ধার করা প্রয়োজন, যা অনেক সময় নিতে পারে। সময়

আরআর একটি দুর্দান্ত সময়সূচী যদি আমরা শুধুমাত্র প্রতিক্রিয়া সময় মেট্রিক সম্পর্কে কথা বলি। কিন্তু কিভাবে টাস্ক টার্নরাউন্ড টাইম মেট্রিক এই অ্যালগরিদমের সাথে আচরণ করবে? উপরের উদাহরণটি বিবেচনা করুন, যখন A, B, C = 5s এর অপারেটিং সময় এবং একই সময়ে পৌঁছায়। টাস্ক A শেষ হবে 13 এ, B 14 এ, C 15 সেকেন্ডে এবং গড় পরিবর্তনের সময় হবে 14 সেকেন্ডে। এইভাবে, RR হল টার্নওভার মেট্রিকের জন্য সবচেয়ে খারাপ অ্যালগরিদম।

আরও সাধারণ পরিভাষায়, যেকোনো RR-টাইপ অ্যালগরিদম ন্যায্য; এটি CPU সময়কে সমস্ত প্রক্রিয়ার মধ্যে সমানভাবে ভাগ করে। এবং এইভাবে, এই মেট্রিকগুলি ক্রমাগত একে অপরের সাথে দ্বন্দ্ব করে।

এইভাবে, আমাদের বেশ কয়েকটি বিপরীত অ্যালগরিদম রয়েছে এবং একই সময়ে এখনও বেশ কয়েকটি অনুমান বাকি রয়েছে - যে টাস্কের সময়টি পরিচিত এবং কাজটি শুধুমাত্র CPU ব্যবহার করে।

I/O এর সাথে মেশানো

প্রথমত, আসুন অনুমান 4টি সরিয়ে ফেলি যে প্রক্রিয়াটি শুধুমাত্র CPU ব্যবহার করে; স্বাভাবিকভাবেই, এটি এমন নয় এবং প্রক্রিয়াগুলি অন্যান্য সরঞ্জামগুলি অ্যাক্সেস করতে পারে।

যে মুহুর্তে কোনো প্রক্রিয়া একটি I/O অপারেশনের অনুরোধ করে, প্রক্রিয়াটি অবরুদ্ধ অবস্থায় প্রবেশ করে, I/O সম্পূর্ণ হওয়ার জন্য অপেক্ষা করে। যদি I/O হার্ড ড্রাইভে পাঠানো হয়, তাহলে এই ধরনের অপারেশনটি কয়েক ms বা তার বেশি সময় নিতে পারে এবং প্রসেসরটি এই মুহূর্তে নিষ্ক্রিয় থাকবে। এই সময়ের মধ্যে, শিডিউলকারী অন্য কোন প্রক্রিয়ার সাথে প্রসেসর দখল করতে পারে। পরবর্তী সিদ্ধান্তটি নির্ধারণকারীকে নিতে হবে যখন প্রক্রিয়াটি তার 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-এর জন্য অপেক্ষা করছে, অন্যান্য প্রক্রিয়াগুলি প্রসেসরে চালানো যেতে পারে।

ওরাকল আর নেই

এখন চলুন এই অনুমান থেকে পরিত্রাণ পেতে চেষ্টা করি যে টাস্কের চলমান সময় জানা যায়। এটি সাধারণত সম্পূর্ণ তালিকার সবচেয়ে খারাপ এবং সবচেয়ে অবাস্তব অনুমান। প্রকৃতপক্ষে, গড় সাধারণ ওএস-এ, ওএস নিজেই সাধারণত কার্য সম্পাদনের সময় সম্পর্কে খুব কমই জানে, তাহলে কীভাবে আপনি কাজটি সম্পাদন করতে কতক্ষণ সময় নেবে না জেনে একটি শিডিয়ুলার তৈরি করতে পারেন? সম্ভবত আমরা এই সমস্যা সমাধানের জন্য কিছু RR নীতি ব্যবহার করতে পারি?

ফলাফল

আমরা টাস্ক শিডিউলিংয়ের প্রাথমিক ধারণা দেখেছি এবং শিডিউলারের 2টি পরিবারকে দেখেছি। প্রথমটি প্রথমে সংক্ষিপ্ততম কাজটি শুরু করে এবং এইভাবে টার্নঅ্যারাউন্ড টাইম বাড়ায়, যখন দ্বিতীয়টি সমস্ত কাজের মধ্যে সমানভাবে ছেঁড়া হয়, প্রতিক্রিয়া সময় বাড়িয়ে দেয়। উভয় অ্যালগরিদম খারাপ যেখানে অন্য পরিবারের অ্যালগরিদম ভাল। আমরা CPU এবং I/O-এর সমান্তরাল ব্যবহার কীভাবে কর্মক্ষমতা উন্নত করতে পারে তাও দেখেছি, কিন্তু OS ক্লেয়ারভায়েন্সের সাথে সমস্যার সমাধান করিনি। এবং পরবর্তী পাঠে আমরা এমন একজন পরিকল্পনাকারীর দিকে তাকাব যেটি নিকট অতীতের দিকে নজর দেয় এবং ভবিষ্যতের ভবিষ্যদ্বাণী করার চেষ্টা করে। এবং একে মাল্টি-লেভেল ফিডব্যাক কিউ বলা হয়।

উত্স: www.habr.com