Theory
करोड़ों रुपये का Dead Air
कल्पना कीजिए यह 1950 है। आपका college करोड़ों रुपये का एक computer ख़रीदता है। कोई Windows नहीं, कोई Linux नहीं, और कोई operating system बिल्कुल नहीं। एक सरल addition program चलाने के लिए, आपको एक time slot book करना होगा, कमरे में जाना होगा, toggle switches ख़ुद पलटने होंगे, punch cards डालने होंगे, और इंतज़ार करना होगा। अगर आपके code में एक typo है, पूरा computer पूरी तरह बेकार बैठा रहता है जब तक आप error खोजते हैं। processor time की यह भारी बर्बादी Operating System के जन्म तक ले गई।
Theory
एकल Printing Press
शुरुआती computers को एक high speed printing press की तरह सोचिए। पहले, authors अपने papers एक-एक करके लाते, ink set up करने में घंटों लगाते, दो मिनट print करते, और press के बिना इस्तेमाल पड़े रहते हुए साफ़-सफ़ाई करते। इस बर्बादी को ठीक करने के लिए, owners ने एक operator hire किया। इस operator ने मिलती-जुलती किताबें एक साथ group कीं (Batch), मौजूदा किताब print होते हुए अगली किताब की ink तैयार की (Multiprogramming), और आख़िरकार कई authors को press background में चलते हुए एक साथ text edit करने दिया (Time Sharing)।
Theory
विकास की औपचारिक Timeline
evolution of operating systems मैनुअल hardware manipulation से automated resource management तक का ऐतिहासिक संक्रमण है। पीढ़ियों में प्राथमिक लक्ष्य हमेशा CPU utilization अधिकतम करना रहा है: processor को व्यस्त रखना। यह Serial Processing (एक user, कोई OS नहीं) से, Batch Operating Systems (setup time घटाने के लिए jobs group करना) तक, Multiprogramming (कई jobs memory में रखना) तक, और आख़िर में Time Sharing Systems (हमारे मौजूदा LabOne server जैसे multi-user interactive systems) तक बढ़ा।
At a glance
performance bottlenecks पर केंद्रित operating systems का विकासात्मक roadmap।
| युग | OS पीढ़ी | मुख्य Technique | प्राथमिक लक्ष्य |
|---|---|---|---|
| 1940s से 1950s | Serial Processing | Punch cards और switches | एक code पूरी तरह चलाना |
| 1950s से 1960s | Simple Batch OS | Resident Monitor jobs group करता है | setup time घटाना |
| 1960s से 1970s | Multiprogramming | कई jobs RAM में | CPU usage अधिकतम करना |
| 1970s आगे | Time Sharing | CPU time slicing | response time न्यूनतम करना |
Think first
Exam Question Walkthrough
university exams अक्सर पूछते हैं: 'Multiprogramming ने Batch Processing को क्यों बदला?' कदम-दर-कदम जवाब प्रकट करने के लिए tap करने से पहले batch processing की मूल सीमा के बारे में सोचिए।
Show the answer
Step 1: bottleneck पहचानिए। एक Batch OS में, जब एक job को एक tape से पढ़ना या print करना होता है (I/O operations), CPU पूरी तरह बेकार बैठता है। I/O CPU से हज़ारों गुना धीमा है।
Step 2: समाधान परिभाषित कीजिए। Multiprogramming इसे कई jobs को main memory में एक साथ रखकर सुलझाता है।
Step 3: संक्रमण mechanism बताइए। अगर Job A I/O करने जाता है, OS तुरंत CPU को Job B execute करने के लिए switch कर देता है। CPU कभी धीमे mechanical devices का इंतज़ार नहीं करता, efficiency को नाटकीय रूप से सुधारते हुए।
Quiz
एक Simple Batch Operating System में, उस ख़ास software का नाम क्या था जो jobs के क्रम को manage और चलाने के लिए स्थायी रूप से main memory में रहता था?
- Kernel
- Resident Monitor
- Command Prompt
- BIOS
Show the answer
Resident Monitor
Resident Monitor आधुनिक OS kernel का आदिम पूर्वज था। यह स्थायी रूप से memory में रहता था (इसलिए resident) और मानव हस्तक्षेप के बिना एक tape batch से अगला job अपने-आप load करता था। शब्द Kernel बाद में उन्नत architectures के साथ आया।
Quiz
एक Multiprogramming system में क्या होता है जब वर्तमान में execute हो रहे program को एक disk read operation का इंतज़ार करना होता है?
- CPU disk read ख़त्म होने तक पूरी तरह बेकार बैठता है।
- operating system पूरे system को रोकता और restart करता है।
- OS CPU को memory में तैयार किसी दूसरे job पर switch कर देता है।
- program अपने ख़ुद के CPU logic से disk read सँभालता है।
Show the answer
OS CPU को memory में तैयार किसी दूसरे job पर switch कर देता है।
यह multiprogramming की मूल परिभाषा है। धीमे I/O operations के दौरान CPU को बेकार बैठने देने के बजाय (Batch systems की बड़ी ख़ामी), OS CPU utilization ऊँची रखने के लिए RAM में एक दूसरे तैयार job पर context switch करता है।
Watch out
Multiprogramming बनाम Multitasking की उलझन
अपने जवाबों में Multiprogramming और Time Sharing शब्दों को अदल-बदल कर इस्तेमाल मत कीजिए। Multiprogramming में, CPU jobs तभी switch करता है जब मौजूदा job एक I/O wait शुरू करता है। तेज़ बातचीत की कोई guarantee नहीं है। Time Sharing में, CPU एक clock timer (time slices) के आधार पर हर कुछ milliseconds में jobs switch करता है। यह वह भ्रम देता है कि LabOne पर कई users एक साथ system इस्तेमाल कर रहे हैं।
Formula
Exam जवाब की Recipe
OS evolution के बारे में एक लंबा जवाब लिखते समय, पूरे marks के लिए इस संरचनात्मक checklist का उपयोग कीजिए:
- arrows इस्तेमाल करते हुए एक कालानुक्रमिक block diagram बनाइए: Serial → Batch → Multiprogramming → Time Sharing।
- Batch systems के तहत 'Resident Monitor' परिभाषित कीजिए।
- साफ़-साफ़ बताइए कि विकास का चालक बल bottleneck को मानव गति से memory गति में, और आख़िर में interactive user गति में स्थानांतरित करना था।
Summary
Key takeaways
- Serial processing में कोई OS नहीं था, मैनुअल setup के दौरान भारी CPU idle time तक ले जाते हुए।
- Batch systems ने मिलते-जुलते jobs के समूह load करना automate करने के लिए Resident Monitor पेश किया।
- Multiprogramming ने कई programs को memory में load करके और I/O waits के दौरान jobs switch करके CPU utilization अधिकतम किया।
- Time sharing systems ने LabOne जैसा एक अत्यधिक interactive, multi-user माहौल बनाने के लिए time slicing पेश किया।
- Memory hook: मैनुअल तारों से batched tapes तक, व्यस्त CPUs से micro-seconds साझा करने तक!