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 વહેંચવા સુધી!