Någon som kan förklara det här med realtidssystem vilket det verkar finnas en hel djungel av som stödjer alla möjliga olika processorer. Alltså från vanliga intel-processorer till picar..
Vad har man dem till?
Realtidssystem
Huvudpoängen med RTOS (Real Time OS) jämfört med GPOS (General Purpose OS) är att ett RTOS ska göra rätt sak innan en viss tid annars händer något hemskt, alltså rätt svar i rätt tid. Att det finns så många beror på att det finns så många applikationer. Alltifrån att ABS-bromsar och antispinn till styrning av industriprocesser och dvd-spelare.
Sen finns det två huvudsakliga kategorier RTOS, hårda och mjuka. Hårda system så lider någon stor skada om en deadline inte möts (ex: kärnreaktor överhettas). Mjuka system brukar man säga förlorar i kvalitet om en deadline missas (ex: dvd-spelaren som hackar).
Sen finns det två huvudsakliga kategorier RTOS, hårda och mjuka. Hårda system så lider någon stor skada om en deadline inte möts (ex: kärnreaktor överhettas). Mjuka system brukar man säga förlorar i kvalitet om en deadline missas (ex: dvd-spelaren som hackar).
En annan nivå på förklaring:
Ett RTOS (eller annat OS för den delen) är ett abstraktionslager för hårdvaran som gör det enklare att köra flera processer samtidigt med samma processor. I realtidssystemet fall måste operativsystemet ha så pass bra koll på processerna (trådarna) och tiden att de kan ge sken av att exekveras parallellt.
Fördelen med RTOS är att det så klart blir lättare att få en processor att göra flera olika saker.
Nackdelen är att man har ett mellanskikt som kräver en hel del RAM (beroende på trådarnas omfattning). Eftersom ett operativsystem är ett abstraktionslager så medför det att man inte längre har direkt kontroll på när ens processer exekveras. Ett annat problem (eller utmaning!) är när processerna behöver kommunicera med varandra.
Ett RTOS (eller annat OS för den delen) är ett abstraktionslager för hårdvaran som gör det enklare att köra flera processer samtidigt med samma processor. I realtidssystemet fall måste operativsystemet ha så pass bra koll på processerna (trådarna) och tiden att de kan ge sken av att exekveras parallellt.
Fördelen med RTOS är att det så klart blir lättare att få en processor att göra flera olika saker.
Nackdelen är att man har ett mellanskikt som kräver en hel del RAM (beroende på trådarnas omfattning). Eftersom ett operativsystem är ett abstraktionslager så medför det att man inte längre har direkt kontroll på när ens processer exekveras. Ett annat problem (eller utmaning!) är när processerna behöver kommunicera med varandra.
Nu är det förvirrat här... 
I de allra flesta OS är en "process" en enhet som kan startas och stoppas
oberoende av andra processer. Process är (normalt) inte = tråd/thread.
I de OS som stöder "multi-threading" kan sedan en process delas upp
i två eller flera "trådar". Dessa trådar kan sedan köras delvis oberoende
av varandra på t.ex multipla processorer eller på processorer med flera
kärnor. Alla dessa trådar körs dock helt och hållet under samma process,
och kommer att försvinna tillsammans om processen försvinner. En "tråd"
kan normalt inte existera utan att det finns en process som "äger" den.
Hurvida OS'et stöder trådar eller inte har inget med hur "RT" det är.
> och är det som ger upphov till de största problemen med RTOS, att trådar inte kan köras parallelt.
Inte alls. Om du har en 1-processor/1-kärne maskin, så kan du naturligtsivs
fortfarande köra en "RTOS" på den oavsett att den naturligtsvis inte kan
köra flera processor (eller trådar) parallelt (eller "samtidigt").
RTOS (eller inte) handlar i princip enbart på hur bra (eller inte) OS'et är
på att reagera på händelser *utanför* OS'et. T.ex så har ett RTOS alltid
ett väl utbyggt interrupt stöd och hur snabbt en process kan reagare på
ett interrupt är på sätt och vis ett mått på hur bra "RT" OS'et är.
Motsatsen till RTOS skulle kunna vara "time shareing" (TS) där processortiden
tilldelas de olika processoerna enligt ett roterande schema ("Round Robin")
oavsett vad som händer "utanför" maskinen.
De flesta OS är en kombination av TS or RT i olika grad. MVS t.ex är ett
nästan rent TS-OS, VMS är en kombination, medan OS som primärt är avsedda
för mindre ("inbyggda") system oftast har sin tyngdpunkt på RT delen. Allt
är design avvägningar mot vad OS'et primär är avsett för.
I princip är alla "OS" avsedda för mindre mikrokontroller system RTOS...
I de allra flesta OS är en "process" en enhet som kan startas och stoppas
oberoende av andra processer. Process är (normalt) inte = tråd/thread.
I de OS som stöder "multi-threading" kan sedan en process delas upp
i två eller flera "trådar". Dessa trådar kan sedan köras delvis oberoende
av varandra på t.ex multipla processorer eller på processorer med flera
kärnor. Alla dessa trådar körs dock helt och hållet under samma process,
och kommer att försvinna tillsammans om processen försvinner. En "tråd"
kan normalt inte existera utan att det finns en process som "äger" den.
Hurvida OS'et stöder trådar eller inte har inget med hur "RT" det är.
> och är det som ger upphov till de största problemen med RTOS, att trådar inte kan köras parallelt.
Inte alls. Om du har en 1-processor/1-kärne maskin, så kan du naturligtsivs
fortfarande köra en "RTOS" på den oavsett att den naturligtsvis inte kan
köra flera processor (eller trådar) parallelt (eller "samtidigt").
RTOS (eller inte) handlar i princip enbart på hur bra (eller inte) OS'et är
på att reagera på händelser *utanför* OS'et. T.ex så har ett RTOS alltid
ett väl utbyggt interrupt stöd och hur snabbt en process kan reagare på
ett interrupt är på sätt och vis ett mått på hur bra "RT" OS'et är.
Motsatsen till RTOS skulle kunna vara "time shareing" (TS) där processortiden
tilldelas de olika processoerna enligt ett roterande schema ("Round Robin")
oavsett vad som händer "utanför" maskinen.
De flesta OS är en kombination av TS or RT i olika grad. MVS t.ex är ett
nästan rent TS-OS, VMS är en kombination, medan OS som primärt är avsedda
för mindre ("inbyggda") system oftast har sin tyngdpunkt på RT delen. Allt
är design avvägningar mot vad OS'et primär är avsett för.
I princip är alla "OS" avsedda för mindre mikrokontroller system RTOS...
-
JimmyAndersson
- Inlägg: 26470
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
hmm... nu vet jag inte vad jag skrev, vart ju helt galet det där. Menade: ... kallas för multitasking och är det som ger upphov till de största problemen med RTOS, att processer inte kan köras parallelt.
Det jag menar är att problemet/utmaningen med ett RTOS är att man ska kunna garantera att göra alla saker i tid men bara ha möjlighet att göra n saker samtidigt.
Det jag menar är att problemet/utmaningen med ett RTOS är att man ska kunna garantera att göra alla saker i tid men bara ha möjlighet att göra n saker samtidigt.
Jo, "tasks" istället för "threads" är ju en annan sak...
"Task" kan betyde lite vad som helst beroende på hur varje OS väljer att
definiera begreppet.
>>> de största problemen med RTOS, att processer inte kan köras parallelt.
Här är det fortfarande lite, hm, otydligt.
Det är inte helt klart vad du menar med "parallelt", om du definierar
det begreppet så kan vi diskutera sedan runt det.
Och vad är det för "problem" du syftar på ?
> att man ska kunna garantera att göra alla saker i tid
Samma sak här. All diskussion blir helt meningslös om du inte talar om
vad du menar med "i tid" !!
> men bara ha möjlighet att göra n saker samtidigt.
Vad menar du med "n" ? 1, 2, 3.... upp till vadå ?
Och, v.v definiera "samtidigt" !
(Kor WinXP direkt från hd med svenska tecken...)
"Task" kan betyde lite vad som helst beroende på hur varje OS väljer att
definiera begreppet.
>>> de största problemen med RTOS, att processer inte kan köras parallelt.
Här är det fortfarande lite, hm, otydligt.
Det är inte helt klart vad du menar med "parallelt", om du definierar
det begreppet så kan vi diskutera sedan runt det.
Och vad är det för "problem" du syftar på ?
> att man ska kunna garantera att göra alla saker i tid
Samma sak här. All diskussion blir helt meningslös om du inte talar om
vad du menar med "i tid" !!
> men bara ha möjlighet att göra n saker samtidigt.
Vad menar du med "n" ? 1, 2, 3.... upp till vadå ?
Och, v.v definiera "samtidigt" !
(Kor WinXP direkt från hd med svenska tecken...)
Okej.
>>> de största problemen med RTOS, att processer inte kan köras parallelt.
Multitasking, att genom att växla mellan olika tasks, få det att se ut som att flera tasks genomförs parallellt, på samma gång. Problemet som jag syftar till är att man i de datorsystem som används idag är mer eller mindre tvungen till att använda multitasking. Exempelvis, du har en dator som ska styra ett visst antal reglerprocesser, säg 4 stycken (för enkelhetens skull 4 tasks). Din dator har bara möjligheten att utföra en av dessa uppgifter (tasks) åt gången (1 styck cpu), genom att använda multitasking så ger du sken av att genomföra alla dessa parallelt, oberoende av varandra. Problemet är ju att du bara luras, du genomför en del av en task och sen växlar du till en annan task och gör en liten del på den. Problemet är oberoendet, eller snarare beroendet. I systemet finns det någon resurs som man tvingas dela på, ex.vis. CPU, minne eller något annat. Så problemet med parallelliteten är alltså att man inte har dedikerade resurser och tvingas dela med sig.
> att man ska kunna garantera att göra alla saker i tid
Det som skiljer ett RTOS från ett GPOS är att i ett GPOS är användbarheten endast beroende av beräkningarnas korrekthet (rätt svar användbart, fel svar inte användbart). I ett RTOS är användbarheten även beroende av tiden som svaret levereras (rätt svar men för sent är alltså inte användbart). Därför har alla tasks en deadline (det är denna som avgränssar 'i tid' från 'för sent'). Vissa system (mjuka realtidssystem) så får man en sämre prestanda (QoS, Quality of Service) om man missar deadlines. Andra system (hårda realtiddsystem) misslyckas totalt med risk för stor skada av något slag (ekonomisk förlurst, dödsfall, mm) om en deadline missas.
> men bara ha möjlighet att göra n saker samtidigt.
Här syftade jag till de begränsade resurser som alla system besitter. Det kan röra sig om n st. cpu:er, n st. samtidiga minnesaccesser, eller någon annan resurs, i huvudsak sådana som man tvingas dela med andra tasks, processer eller trådar (beroende på vilken nivå vi befinner oss)
Se även två steg upp i det första lite större stycket.
Definition av samtidigt: Jaa, concurrent på engelska är det mest jag syftar till men det beror även lite på sammanhang, tyvärr.
>>> de största problemen med RTOS, att processer inte kan köras parallelt.
Multitasking, att genom att växla mellan olika tasks, få det att se ut som att flera tasks genomförs parallellt, på samma gång. Problemet som jag syftar till är att man i de datorsystem som används idag är mer eller mindre tvungen till att använda multitasking. Exempelvis, du har en dator som ska styra ett visst antal reglerprocesser, säg 4 stycken (för enkelhetens skull 4 tasks). Din dator har bara möjligheten att utföra en av dessa uppgifter (tasks) åt gången (1 styck cpu), genom att använda multitasking så ger du sken av att genomföra alla dessa parallelt, oberoende av varandra. Problemet är ju att du bara luras, du genomför en del av en task och sen växlar du till en annan task och gör en liten del på den. Problemet är oberoendet, eller snarare beroendet. I systemet finns det någon resurs som man tvingas dela på, ex.vis. CPU, minne eller något annat. Så problemet med parallelliteten är alltså att man inte har dedikerade resurser och tvingas dela med sig.
> att man ska kunna garantera att göra alla saker i tid
Det som skiljer ett RTOS från ett GPOS är att i ett GPOS är användbarheten endast beroende av beräkningarnas korrekthet (rätt svar användbart, fel svar inte användbart). I ett RTOS är användbarheten även beroende av tiden som svaret levereras (rätt svar men för sent är alltså inte användbart). Därför har alla tasks en deadline (det är denna som avgränssar 'i tid' från 'för sent'). Vissa system (mjuka realtidssystem) så får man en sämre prestanda (QoS, Quality of Service) om man missar deadlines. Andra system (hårda realtiddsystem) misslyckas totalt med risk för stor skada av något slag (ekonomisk förlurst, dödsfall, mm) om en deadline missas.
> men bara ha möjlighet att göra n saker samtidigt.
Här syftade jag till de begränsade resurser som alla system besitter. Det kan röra sig om n st. cpu:er, n st. samtidiga minnesaccesser, eller någon annan resurs, i huvudsak sådana som man tvingas dela med andra tasks, processer eller trådar (beroende på vilken nivå vi befinner oss)
Se även två steg upp i det första lite större stycket.
Definition av samtidigt: Jaa, concurrent på engelska är det mest jag syftar till men det beror även lite på sammanhang, tyvärr.
Att säga att det är motsatsen är väl ändå att ta i lite. VxWorks tex använder ett Round Robin tillägg i dess cpu skedulering för att hantera fall då flera trådar som delar på en cpu har samma prioritet.sodjan skrev:Motsatsen till RTOS skulle kunna vara "time shareing" (TS) där processortiden tilldelas de olika processoerna enligt ett roterande schema ("Round Robin")
oavsett vad som händer "utanför" maskinen.
*Begreppsmässigt* kan man se på det som motsatser.
Sen har du naturligtsvis helt rätt i att nästan alla OS tillämpar en
kombination av olika scheduling metoder. Vilket som väger tyngst
i varje specifikt OS beror på vad man hade för design kriterier när
OS'et konstruerades. Det är väldigt ovanligt med rena TS resp RT OS.
Det närmaste ett rent TS-OS jag kan tänka mig är MVS (alltså det som
körs på IBM's stordatorer). Där handlar det (ofta) enbart om att köra olika
"job" som enbart jobbar mot disk, terminaler och skrivare, vilket går
utmärkt att "time-share'a"
Det som kännetecknar "RT" är förmågan att reagera på (och prioritera)
olika asynkrona händelser (ofta externa från den process som OS'et
kontrollerar)
Sen har du naturligtsvis helt rätt i att nästan alla OS tillämpar en
kombination av olika scheduling metoder. Vilket som väger tyngst
i varje specifikt OS beror på vad man hade för design kriterier när
OS'et konstruerades. Det är väldigt ovanligt med rena TS resp RT OS.
Det närmaste ett rent TS-OS jag kan tänka mig är MVS (alltså det som
körs på IBM's stordatorer). Där handlar det (ofta) enbart om att köra olika
"job" som enbart jobbar mot disk, terminaler och skrivare, vilket går
utmärkt att "time-share'a"
Det som kännetecknar "RT" är förmågan att reagera på (och prioritera)
olika asynkrona händelser (ofta externa från den process som OS'et
kontrollerar)
Rohan, din beskrivning av multitasking är väl hyggligt OK, även om den
är kraftigt förrenklad, och jag inte riktigt ser vad som är "problemet". Det du
kallar för ett "problem" är bara *en* egenskap hos OS'et som man som
konstruktiör/programmerare får ta hänsyn till.
> Definition av samtidigt: Jaa, concurrent på engelska är det mest jag syftar till...
Nu var det inte en översättning jag tänkte på
Vad jag menade var att i bland kan "samtidigt" betyda "inom samma sekund",
ibland "inom samma millisekund" o.s.v.
Därför är det ganska ointressant att använda ett begrepp som "samtidigt" i
generella diskussioner eller för att kategorisera ett OS som "RT" eller inte...
Coore> Jag skulle snarare säga att det som kännetecknar ett RT är
> förmågan att garantera att processer hinner att slutföras innan dess
> deadline.
Vadå "dess deadline" ? Finns det OS där man kan sätta en "deadline" på tasks/processer ?
Och hur hanterar i så fall OS'et det fall där "deadline" passeras ??
Om inte någonting hinner bli klart "i tid" så är det programmerarens fel, inget annat...
är kraftigt förrenklad, och jag inte riktigt ser vad som är "problemet". Det du
kallar för ett "problem" är bara *en* egenskap hos OS'et som man som
konstruktiör/programmerare får ta hänsyn till.
> Definition av samtidigt: Jaa, concurrent på engelska är det mest jag syftar till...
Nu var det inte en översättning jag tänkte på
Vad jag menade var att i bland kan "samtidigt" betyda "inom samma sekund",
ibland "inom samma millisekund" o.s.v.
Därför är det ganska ointressant att använda ett begrepp som "samtidigt" i
generella diskussioner eller för att kategorisera ett OS som "RT" eller inte...
Coore> Jag skulle snarare säga att det som kännetecknar ett RT är
> förmågan att garantera att processer hinner att slutföras innan dess
> deadline.
Vadå "dess deadline" ? Finns det OS där man kan sätta en "deadline" på tasks/processer ?
Och hur hanterar i så fall OS'et det fall där "deadline" passeras ??
Om inte någonting hinner bli klart "i tid" så är det programmerarens fel, inget annat...
