Kenmerken van realtime besturingssystemen. Wat is OSRV? Ontwikkeling van moderne besturingssystemen

laat een reactie achter 6,950

Echte tijd? Laten we aandacht besteden aan een gedetailleerde studie van RTOS. Allereerst zijn dit speciale typen die verschillen van universele besturingssystemen in hun prestaties en prestaties in de slechtste situaties. Er zijn veel concepten die de details onthullen:

RTOS is een systeem dat in staat is om: vereiste service gedurende een bepaalde tijdsperiode;

Realtime systeem, dat wordt gekenmerkt door constante gereedheid en het tijdstip van de verwerkte informatie is onzichtbaar voor gebruikers;

- “snel systeem”, Waarbij de prioriteit niet de responstijd van de RTOS is, maar de voldoende tijd om met de applicatie te werken.

Om het plaatje compleet te maken, moet je letten op: kenmerken besturingssystemen echte tijd. Het meest belangrijk kenmerk is een gegarandeerd en stabiel antwoord op lopende gebeurtenissen. Taken van elk niveau (hoge en lage prioriteit) mogen niet met elkaar in strijd zijn en elkaar verdringen. Hoog niveau realtime responstijdvereisten voor een specifieke gebeurtenis.

Echte tijd

Ze zijn onderverdeeld afhankelijk van de programma's: hard (hard), zacht (zacht) en interactief. Laten we een snelle blik op elke soort.

Harde RTOS hebben strikt: bepaalde tijd reactie op een gebeurtenis in realtime. Voorbeeld: hardware-onderbreking, moet de weergave van besturingscommando's worden verwerkt waarvoor dit in 100% van de gevallen gebeurt.

Realtime zachte systemen laten in 80-90% van de gevallen toe om één orde van grootte af te wijken van een bepaald tijdsbestek. Maar het belangrijkste is dat deze vertragingen niet tot onherstelbare gevolgen mogen leiden.

Interactieve RTOS wordt ingeschakeld (wanneer een persoon een reactie van het systeem verwacht na gegeven instructies of opdrachten).

De meest voorkomende realtime besturingssystemen en hun kenmerken

De meeste RTOS - gesloten type en het is moeilijk om over hen te komen gedetailleerde informatie... WindRiver Systems ontwikkelde VxWorks (hard RTOS) voor softwareontwikkeling op embedded pc's. Het is gebaseerd op de werking van de hostcomputer, waarop de software wordt ontwikkeld, en de clientcomputer, waar deze wordt gebruikt onder controle van VxWorks.

Deze realtime besturingssystemen zijn in hoge mate aanpasbaar, maar softwaremodules kunnen niet in een andere omgeving worden gebruikt, waardoor ze eerder beperkt in gebruik zijn. De voordelen zijn onder meer:

Onbeperkt aantal op te lossen taken.

Het aantal prioritaire taken is maximaal 256.

Taken worden cyclisch of per prioriteit gepland.

Semaforen om te helpen bij het beheren van kritieke systeembronnen.

QNX Neutrino Realtime Operating System is het geesteskind van QNX Software Systems. Het is gebaseerd op een cross-server-architectuur en is zeer multitasking met een prioriteitsmodus. Elk element van het systeem werkt onafhankelijk: in geval van storingen en storingen kan elke link zichzelf herstarten zonder de werking van de kernel of andere componenten te beïnvloeden. Het heeft ook een diepe configuratie, die bindt aan de onderliggende kern, wat het werken in een andere omgeving uitsluit.

ChorusOS biedt een voorbeeld van een ingebed besturingssysteem dat veel wordt gebruikt in telecommunicatie. Het ondersteunt verschillende telecommunicatieprotocollen, Java-technologieën, die de introductie van nieuwe ontwikkelingen en toepassingen mogelijk maken.

Verschil met besturingssysteem normaal gebruik en bestemming

RTOS verschilt van systemen algemeen doel deterministische aard van het werk, wat te wijten is aan strikte controle van de tijd die aan het verwerken van taken wordt besteed. Bepaling beschrijft een vooraf bepaald tijdsinterval waarin één realtime programma wordt uitgevoerd.

Het beheer van automatische of geautomatiseerde complexen die hoge eisen stellen aan de tijd die nodig is om taken uit te voeren, wordt uitgevoerd door realtime besturingssystemen. Ze bieden gegarandeerde responstijden op externe gebeurtenissen en minimale vertragingen.

Realtime besturingssysteem, OS RV(Engels real-time besturingssysteem) - een type, in de regel, met een speciaal doel. Er zijn verschillende definities voor deze term, die elkaar soms tegenspreken:

Een besturingssysteem waarin het succes van een programma niet alleen afhangt van de logische juistheid ervan, maar ook van de tijd waarin het dit resultaat heeft ontvangen. Als het systeem de tijdsbeperkingen niet aankan, moet een storing in de werking worden geregistreerd.
De POSIX 1003.1-standaard definieert: "Realtime in besturingssystemen is het vermogen van het besturingssysteem om het vereiste serviceniveau in een bepaalde periode te bieden."
Besturingssysteem dat op een voorspelbaar tijdstip reageert op het onvoorspelbare optreden van externe gebeurtenissen
Interactieve systemen van constante paraatheid. Ze worden ingedeeld in de categorie RT OS op basis van marketingoverwegingen en als: interactief programma heet "werken in realtime", het betekent alleen dat verzoeken van de gebruiker worden verwerkt met een voor mensen onzichtbare vertraging.
Soms wordt het concept van een realtime systeem gelijkgesteld met een "snel systeem", maar dit is niet altijd correct, aangezien het niet de vertragingstijd van de RT OS-respons is die belangrijk is, maar dat deze tijd voldoende is voor de toepassing overwogen en het is gegarandeerd.
Veel gespecialiseerde vakgebieden introduceren hun eigen concepten van "realtime". Bijvoorbeeld het proces digitale verwerking signaal wordt realtime genoemd als de analyse en/of datageneratie in dezelfde tijd kan worden uitgevoerd als de analyse/generatie van dezelfde data zonder digitale signaalverwerking. Als het verwerken van audiogegevens bijvoorbeeld 2,01 seconden nodig heeft om 2,00 seconden audio te analyseren, dan is dit geen realtime proces. Als het 1,99 seconden duurt, is dit een realtime proces.

Realtime systemen worden gekenmerkt door het volgende:

gegarandeerde responstijd op externe gebeurtenissen (bijvoorbeeld op onderbrekingen van apparatuur);
een rigide subsysteem voor het plannen van processen (taken met een hoge prioriteit mogen niet worden vervangen door taken met een lage prioriteit, op enkele uitzonderingen na);
verhoogde vereisten voor de responstijd op externe gebeurtenissen of reactiviteit (de vertraging bij het aanroepen van de interrupt-handler is niet meer dan tientallen microseconden, de vertraging bij het schakelen van taken is niet meer dan honderden microseconden)

Een klassiek voorbeeld van een taak waarbij een RT OS vereist is, is de besturing van een robot die een onderdeel van een lopende band neemt. Het onderdeel beweegt en de robot heeft maar een kleine hoeveelheid tijd om het op te rapen. Als hij te laat is, is de rol niet meer aan het gewenste gebied transportband, en daarom zal het werk niet worden gedaan, ondanks het feit dat de robot in de juiste plek... Staat het eerder, dan heeft het onderdeel nog geen tijd om omhoog te rijden en blokkeert het zijn pad.

Soorten RT OS

De dynamische eigenschappen van real-time programma's worden meestal gekenmerkt door drie definities: programma's "Hard" (hard), "zacht" (zacht) en interactief ("conditioneel") echte tijd.

Moeilijk echte tijd ... Zorgt voor een gegarandeerde reactietijd van het systeem op een specifieke gebeurtenis, bijvoorbeeld een hardware-onderbreking, het geven van een besturingsopdracht, enz. De absolute waarde van de responstijd maakt niet zoveel uit. Dus als het nodig is voor het programma om een commando in 1 milliseconde uit te voeren, maar het kan deze taak slechts in 95% van de gevallen aan, en in 5% past het niet in de standaard, dan kan een dergelijk systeem niet worden gekarakteriseerd als werkend in harde realtime. Als het team binnen een uur moet worden uitgewerkt, wat in 100% van de gevallen gebeurt, is er sprake van lastige realtime.

In de meeste Russischtalige literatuur worden dergelijke systemen systemen met deterministische tijd... Bij praktische toepassing de reactietijd moet minimaal zijn.

Zachte realtime... In dit geval is de verwachte responstijd van het systeem eerder indicatief dan richtinggevend. Uiteraard wordt aangenomen dat in de meeste gevallen (80 - 90 procent) de respons binnen de gestelde limieten zal liggen. Maar ook andere opties - waaronder volledige afwezigheid systeemreacties - mogen niet tot rampzalige resultaten leiden. Meestal wordt aangenomen dat als de tijdslimiet met één orde van grootte wordt overschreden, dit nog steeds draaglijk is.

Interactieve realtime... Is meer psychologisch dan technische eigenschappen... Bepaalt de tijd gedurende welke de operator - een mens - in staat is om rustig, zonder nervositeit, te wachten op de reactie van het systeem op de hem gegeven instructies. Als voorbeeld kunnen we de spellen noemen die tegenwoordig erg populair zijn uit de categorie "real-time strategie" (zie bijvoorbeeld een quasar gebaseerd op Warhammer).

In realtime systemen is het noodzakelijk om een bepaalde regieperiode in te voeren (in de Engelstalige literatuur - deadline), vóór het verstrijken waarvan de taak noodzakelijkerwijs (voor zachte real-time systemen - wenselijk) moet worden uitgevoerd. Deze deadline wordt door de taakplanner gebruikt om zowel een prioriteit toe te kennen aan een taak wanneer deze begint als bij het kiezen van een uit te voeren taak.

Vaak wordt SRV onvoorwaardelijk opgevat als: ingebedde besturingssystemen in feite is er een verschil tussen real-time systemen en embedded systemen. Een embedded systeem hoeft niet altijd voorspelbaar gedrag te vertonen, in dat geval is het geen realtime systeem. Zelfs een snelle blik op mogelijke embedded systemen suggereert echter dat de meeste embedded systemen voorspelbaar gedrag nodig hebben, volgens: minstens, voor sommige functionaliteit, en dus kunnen deze systemen worden geclassificeerd als realtime-systemen.

Basisvereisten voor RT OS

Martin Timmerman (directeur van embedded systems ontwikkelaar Dedicated Systems Experts) formuleerde de volgende noodzakelijke eisen voor het RT OS:

OS moet verwijderbaar en multitasking zijn,
OS moet het concept van prioriteit hebben voor threads,
OS moet voorspelbare synchronisatiemechanismen ondersteunen,
Het besturingssysteem moet een mechanisme bieden voor het overnemen van prioriteiten,
Het gedrag van het besturingssysteem moet bekend en voorspelbaar zijn (vertragingen bij de verwerking van onderbrekingen, vertragingen bij het wisselen van taken, vertragingen van de bestuurder, enz.); dit betekent dat in alle scenario's voor systeembelasting, a maximale tijd antwoord.

Kenmerken van de RT OS-architectuur

In de afgelopen 25-30 jaar is de structuur van besturingssystemen geëvolueerd van een monolithische naar een meerlagige OS-structuur en verder naar een client-server-architectuur. Deze oplossingen hebben tot op zekere hoogte hun toepassing gevonden in de ontwikkeling van realtime besturingssystemen.

Monolithische architectuur vertegenwoordigt een systeem dat bestaat uit een set van op elkaar inwerkende modules. Applicaties hebben toegang tot het systeem via de modules-API. Wijzigingen aan de ene module hebben invloed op andere modules. Hoe meer modules, hoe complexer ze met elkaar verbonden zijn, hoe minder voorspelbaar het gedrag van een dergelijk systeem tijdens het gebruik. Bovendien doen zich problemen voor bij het gebruik van dit type besturingssysteem in een gedistribueerd systeem met meerdere processors.

Figuur 1. Monolithische architectuur van RT OS

Meerlagige architectuur beschrijft een systeem dat bestaat uit meerdere functionele niveaus... Een applicatie heeft toegang tot hardwarebronnen zowel via: systeemoproepen pitten en systeemdiensten en door API-niveaus... In feite is de mogelijkheid om toegang te krijgen tot de onderliggende lagen zonder hogere niveaus semantisch incorrect, maar voor real-time systemen kan zo'n organisatie de voorspelbaarheid van het systeem vergroten en de responstijd verkorten. Het nadeel van gelaagde architectuur is dat veranderingen aan één laag aangrenzende lagen beïnvloeden. Een ander nadeel dat inherent is aan meerlaagse architectuur is het gebrek aan multitasking. Niet altijd en niet alle realtime systemen hebben echter ondersteuning voor multitasking nodig. Het is bijvoorbeeld moeilijk om de noodzaak van multitasking voor een embedded OS te rechtvaardigen. industriële robot toevoer van onderdelen naar de transportband.

Fig. 2. RV OS meerlagige architectuur

Client-server-architectuur Het besturingssysteem is gebaseerd op het minimaliseren van het aantal functies dat door de kernel wordt uitgevoerd (meer precies, microkernel) van een dergelijk systeem. Op kernelniveau worden bijvoorbeeld alleen de planner, de synchronisatieprimitieven en de berichtenservice uitgevoerd. Alle andere functionaliteit wordt naar het gebruikersniveau gebracht en via servers geïmplementeerd. Clienttoepassingen hebben toegang tot en ontvangen antwoorden van hen door berichten uit te wisselen via de kernel-berichtenservice.

Fig. 3 Client-server-architectuur van RT OS

De client-server-architectuur maakt schaalbare besturingssystemen mogelijk en vereenvoudigt de distributie op een systeem met meerdere processors. Tijdens de werking van het systeem veroorzaakt de vervanging van één module geen "sneeuwbaleffect"; bovendien leidt een storing van een module niet altijd tot een storing van het systeem als geheel. een kans hebben dynamisch laden en losmodules. Het hoofdprobleem in dit model is geheugenbescherming, aangezien serverprocessen moet worden beschermd. Elke keer dat een serviceverzoek wordt gedaan, moet het systeem overschakelen van de applicatiecontext naar de servercontext. Met de ondersteuning van geheugenbescherming neemt de schakeltijd van het ene proces naar het andere toe.

Controlevragen

Geef een definitie van een realtime besturingssysteem
Wat deadline?
Wat is het verschil "Moeilijk" realtime van "Zacht"
Formuleer de basisvereisten voor RT OS
Geef de belangrijkste verschillen aan in de vereisten voor RT OS van universeel OS
Beschrijf modulaire architectuur
Beschrijf gelaagde architectuur
Beschrijf de client-server-architectuur

Het vaste adres van deze pagina is:

Wat is realtime?

Er zijn verschillende definities van het concept van realtime, die elkaar vaak tegenspreken, waardoor het helaas niet mogelijk is om één enkele terminologie aan te nemen. De volgende definitie kan dicht bij de canonieke worden genoemd: "Een realtime systeem is zo'n systeem waarvan de juistheid niet alleen afhangt van de uitvoering van bepaalde taken, maar ook van het tijdstip van uitvoering. Als de tijdparameters van de taak worden geschonden, wordt deze als onvervuld beschouwd." Een aanvulling op deze definitie: “Daarom moet het systeem zelf gegarandeerde tijdparameters hebben, d.w.z. systeemgedrag moet voorspelbaar zijn. Hierdoor kunt u het aantal onvervulde (door schending van tijdparameters) taken minimaliseren."

Een goed voorbeeld van een realtime systeem is een robot die een rol speelt op een lopende band. Als hij te laat is, mist hij één cyclus van de transportband en als hij een onderdeel te vroeg oppakt, kan dit de beweging van andere onderdelen blokkeren. Een ander voorbeeld is een vliegtuig dat op de automatische piloot vliegt. Speciale sensoren bepalen de positie van het vliegtuig in de driedimensionale ruimte. Alleen constante en tijdige ontvangst van deze gegevens boordcomputer garandeert de veiligheid van de vlucht.

Soms wordt het real-time systeem genoemd interactief systeem met snelle responstijd. Beschouw het volgende voorbeeld: Typen in WinWord 2.0 op een computer met: Athlon-processor 1GHz. Reactietijd in in dit geval Is het tijdsinterval tussen het indrukken van een toets en het weergeven van de bijbehorende letter in het programmavenster. Het lijkt duidelijk dat deze waarde in dit geval er niet toe doet - toch typt een persoon langzamer. De fout ligt in de vervanging van concepten - hoge snelheid respons betekent niet dat respons gegarandeerd is. De computer opstarten grote hoeveelheid resource-intensieve taken, kunnen we de responstijd onbeperkt verlengen. Probeer het volgende experiment: De labels van alles plaatsen geïnstalleerde programma's(het is wenselijk dat er onder hen zulke monsterlijke toepassingen waren als Borland Delphi, Microsoft Office, en een paar 3D-shooters) op de Windows95-desktop (bij voorkeur build 450 of eerder :), selecteer ze met de muis en druk op Enter. Daarna zal Windows rommelen harde schijf jongleren met gegevens tussen wisselbestand en geheugen, en nergens op reageren externe invloeden totdat je op drukt Reset knop... Dit is meestal voldoende om te beseffen dat een snel systeem niet per se een realtime systeem is. Aan de andere kant betekent realtime niet de uitvoeringssnelheid van het programma; bovendien zijn algoritmen die eindige responstijden garanderen vaak minder efficiënt dan conventionele algoritmen.

In de Engelstalige literatuur wordt gesproken over "zachte real-time systemen" en "harde real-time systemen", maar in dit geval is software- of hardware-implementatie van een real-time systeem niet bedoeld. De term hard betekent dat de responstijd (LT - latentietijd) hard gecodeerd is, d.w.z. constant is. Het zachte (zachte) real-time systeem (RTS - real-time systeem) kan LT veranderen, wat de efficiëntie van RTS verhoogt en processen met verschillende prioriteiten manipuleert. Om bijvoorbeeld één frame van een videostream te digitaliseren, is LT = 0,033 s (30 frames / sec) voldoende, en voor het proces van het besturen van servoaandrijvingen is het noodzakelijk om een LT-waarde in de orde van tientallen microseconden te bereiken. Soms verwijst de term hard naar het klassieke (hierboven beschreven) RTS-model, en verwijst de term soft naar een systeem dat niet in zijn pure vorm RTS is, maar waarvan de LT is teruggebracht tot het vereiste niveau, waardoor de vereiste gegevensverwerkingssnelheid wordt verkregen. Als een computer met DOS bijvoorbeeld gegevens van een elektronische oscilloscoop verwerkt, dan is dit SoftRTS, omdat: DOS is een besturingssysteem voor één taak en, op voorwaarde dat de computer snel genoeg is en normaal werk oscilloscoop, niets mag ons ervan weerhouden om gegevens met een voldoende snelheid te verwerken (maar we kunnen dit niet garanderen!). In multitasking-besturingssystemen is het ook mogelijk om SoftRTS te implementeren, en het wordt meestal gebruikt in multimediatoepassingen en 3D-games, aangezien ze stellen u in staat om de vereiste LT te leveren door de kwaliteit van de gegevensverwerking te verminderen (de bitrate verlagen, de FPS verlagen, de schermresolutie en kleurdiepte wijzigen).

Realtime besturingssystemen

Om het werkingsprincipe en de basiseigenschappen van real-time besturingssystemen (RTOS - Real Time Operating System) te begrijpen, is de introductie van dergelijke basisdefinities zoals microkernel en macrokernel.

Er zijn twee hoofdscholen voor kernelbouwers (ik kon geen nauwkeurigere vertaling voor kernel vinden)
ontwikkelaars :): de een gelooft dat de kernel van het besturingssysteem compact en snel moet zijn, en de functionaliteit is verspreid over processen, de ander predikt een meer traditionele benadering, waarbij de kernel alles krijgt basisfuncties OS en processen - niets anders dan de mogelijkheid om dezelfde functies aan te roepen. In 1989 introduceerden Ira Goldstein en Paul Dale de term microkernel om het eerste (door opsomming, niet door de tijd van verschijnen) type architectuur aan te duiden. De eerste (nu - in chronologische zin) architectuur van de kernel (traditioneel of monolithisch (monolithisch), zoals het in de Engelstalige literatuur wordt genoemd) heette "macrokernel" (wat duidelijk bewijst laag niveau verbeeldingskracht van programmeurs, vooral systeemprogrammeurs).

Het debat over welke architectuur de beste is, is nog steeds gaande. De meeste UNIX OS-implementaties zijn gebouwd op de macrokernel, inclusief de meest populaire vandaag - Linux en FreeBSD. Op de microkernel zijn besturingssystemen zoals Mach en QNX gebouwd. Sommige systeemingenieurs classificeren Mach echter niet als een microkernel om de reden grote maat kernels (het bevat apparaatstuurprogramma's, wat meer typisch is voor macro-kernels). De tegenovergestelde situatie heeft zich ontwikkeld met de QNX-kern - deze is zo klein (zowel qua grootte als
functionaliteit) die ik moest introduceren nieuwe term- nanokernel. Ik denk dat de geschillen rond Mach op dezelfde manier kunnen worden opgelost, d.w.z. een verandering in terminologie - maar blijkbaar leken de woorden santikernel en decykernel niet welluidend genoeg voor programmeurs. Het moet duidelijk zijn dat het onderscheid tussen OS-microkernels en macrokernels helemaal niet wordt gemaakt door de grootte van de kernel, maar door zijn architectuur, d.w.z. door de verhouding tussen het aantal functies geïmplementeerd in de kernel en functies geïmplementeerd buiten de kernel. Andere parameters (prestaties, flexibiliteit, real-time werking) kunnen niet indicatief zijn voor een dergelijk onderscheid. Bovendien wordt de grens tussen macrokernel en microkernel steeds vager doordat veel moderne monolithische kernels zogenaamde threads bevatten en de mogelijkheid hebben tot "fijnkorrelige" parallellisatie (hoe vertaal je anders fijnkorrelig parallerisme?). Architectonisch gezien lijken dergelijke kernels op microkernels met een groot aantal processen die in gedeeld geheugen draaien.

Het vermogen van een besturingssysteem om in realtime te draaien, wordt grotendeels bepaald door de architectuur van de kernel. Het handigst in dit opzicht zijn microkernels (in feite zijn ze hiervoor ontwikkeld), maar dit betekent niet dat alle microkernels in realtime werken (Mach is een microkernel die niet in realtime werkt, wat helemaal geen afbreuk doet aan van andere voordelen van dit besturingssysteem, dat veel nakomelingen heeft voortgebracht, waaronder NeXTStep, Hurd, BeOS en MacOSX). Het bestaan van een macrokernel met volledige ondersteuning werk in realtime is nog steeds in het geding (ik heb geen informatie over een dergelijk project gevonden, behalve misschien Sun Solaris 2.x, maar naar mijn mening (geen competentie claimt), dit is meer SoftRTS, niet HardRTS), en hier is een gedeeltelijke implementatie - een veel voorkomend iets. In Linux worden bijvoorbeeld de eerder genoemde interprocessor (van de tekstverwerking, niet de processor) threads actief geïmplementeerd, en er bestaat al een groot aantal van toepassingen (de eerste was Apache-webserver) met behulp van deze interface.

QNX RTOS

De meest populaire RTOS in Rusland is QNX 4.0 (eigenlijk Windows NT, maar heb je veel mensen gezien die eTU alleen daarom gebruiken?). Onder andere unix-klonen neemt het ook een zelfverzekerde positie in - de penetratie (d.w.z. het veroverde marktaandeel) van dit besturingssysteem is ongeveer 8-10% - alleen Linux en FreeBSD hebben een grotere prevalentie bereikt (ze hebben ongeveer de helft van Russische markt unix-systemen). Ondanks het feit dat QNX oorspronkelijk commercieel, gesloten en eigendom was, maakt het licentiemodel het nu mogelijk om gratis te verkrijgen en te gebruiken als het besturingssysteem zelf (in minimale configuratie zeker niet voor commercieel gebruik, maar - ik herhaal - helemaal gratis en zonder tijdslimiet) en broncodes (ook niet voor iedereen en niet voor iedereen - maar dit is al veel).

Wat is er zo cool aan dit besturingssysteem? Het feit dat het multitasking, multi-user, modulair en POSIX-compatibel is, zal alleen de bebaarde poolreizigers verrassen die er vast van overtuigd zijn dat de pinguïn dat soort voedsel is :). Dit besturingssysteem is trouwens 2 keer ouder dan Lynuks. Dit is echter geen indicatie. Denk maar aan - een 8K microkernel (ja, acht kilobytes!). Dit is een indicatie! Zo wordt de record-context-schakeltijd van 2,5 nanoseconden bereikt. Het punt is dat de kernel alleen de tijdsverdeling tussen processen en de verzending van berichten beheert. Zelfs het beheer van processen en de toewijzing van middelen voor processen wordt uitgevoerd door een apart programma, de procesmanager genaamd, en het doet dit in overeenstemming met POSIX 1003.4 (dit is een speciale standaard voor RTOS - lees het als u besluit om GNU QNX te doen :).

Andere kenmerken zullen u waarschijnlijk niet interesseren - ze zijn niet bekend en nodig voor elke QNX-professional. Dus ongeveer 12 mogelijke uitdagingen microkernel, 32 prioriteitsniveaus en drie timesharing-algoritmen (FIFO, circulair en adaptief) Ik stotter niet eens.

Maar ik raad je ten zeerste aan om de vereisten voor de apparatuur goed te lezen:

CPU: 8088, 80286, 80386 en hoger
RAM: minder dan 640 KB (voor uitvoering), 2 MB (voor ontwikkeling)
HDD: 5Mb voor OS en hulpprogramma's (voor programmeersysteem)
- nog eens 4Mb); schijfloze configuratie mogelijk.

Denk alleen niet dat de eisen zo bescheiden zijn, want het systeem is primitief. Het meest moderne versie QNX (Neutrino 6.2.1) is bijna net zo resource-hongerig als XP. Ben je bang? 🙂 Ik zei - bijna! Bovendien valt niemand je lastig om QNX4 op 386 in te stellen en ervan te genieten. Bereid je voor op gezondheid!

Ministerie van Onderwijs en Wetenschappen van de Russische Federatie

Volga State Technological University

Discipline abstract

"Realtime besturingssystemen: functies en toepassingen"

Voltooid: student van EF (groep PI-12)

Mikusjov Yu.V.

[e-mail beveiligd]

Docent: Borodin A.V.

Yoshkar-Ola

● Inleiding

● Definitie

● Ontwikkeling van moderne besturingssystemen

● Huidige staat van het onderwerpgebied

● Verschillen met besturingssystemen voor algemeen gebruik

● RTOS-architectuur

● Soorten OS-taken

● Vijf belangrijkste onzichtbare taken van het besturingssysteem

● Functies

●Toepassing

● Markt voor besturingssystemen

● De toekomst van RTOS

● Conclusie

● Lijst met gebruikte bronnen

Invoering

Real-time besturingssystemen (RTOS) zijn ontworpen om een interface te bieden voor de bronnen van tijdkritische real-time systemen. De hoofdtaak in dergelijke systemen is de tijdigheid van de gegevensverwerking.

De belangrijkste vereiste voor RTOS is de vereiste om ervoor te zorgen: voorspelbaarheid of determinisme het gedrag van het systeem in de slechtste externe omstandigheden, dat sterk verschilt van de prestatie- en snelheidsvereisten van algemene besturingssystemen. Een goede RTOS heeft voorspelbaar gedrag onder alle opstartscenario's (gelijktijdige interrupts en thread-uitvoering).

Er is een verschil tussen realtime systemen en embedded systemen. Een embedded systeem hoeft niet altijd voorspelbaar gedrag te vertonen, in dat geval is het geen realtime systeem. Zelfs een snelle blik op mogelijke ingebedde systemen suggereert echter dat de meeste ingebedde systemen voorspelbaar gedrag nodig hebben, althans voor bepaalde functionaliteit, en daarom kunnen deze systemen worden geclassificeerd als realtime-systemen.

Het is gebruikelijk om onderscheid te maken tussen zachte en harde realtime systemen. In harde real-time systemen kan het onvermogen om te reageren op gebeurtenissen in tijd instellen leidt tot weigeringen en de onmogelijkheid om de toegewezen taak te voltooien. In de meeste Russischtalige literatuur worden dergelijke systemen systemen met deterministische tijd genoemd. In praktische toepassingen moeten reactietijden tot een minimum worden beperkt. Systemen die niet onder de definitie van "hard" vallen, worden zachte realtime-systemen genoemd. er is nog steeds geen duidelijke definitie voor in de literatuur. Zachte real-time systemen hebben misschien geen tijd om het probleem op te lossen, maar dit leidt niet tot systeemstoringen als geheel. In real-time systemen is het noodzakelijk om een bepaalde richtlijnperiode (in de Engelstalige literatuur - deadline) in te voeren, vóór het verstrijken waarvan de taak noodzakelijkerwijs (voor zachte real-time systemen - bij voorkeur) voltooid moet zijn. Deze deadline wordt door de taakplanner gebruikt om zowel een prioriteit toe te kennen aan een taak wanneer deze begint als bij het kiezen van een uit te voeren taak.

definities

Een realtime systeem is een type besturingssysteem met als hoofddoel het bieden van de noodzakelijke en voldoende set functies die softwareontwikkeling van realtimesystemen op specifieke hardware mogelijk maken.

Een systeem wordt een realtime systeem genoemd als de juistheid van zijn werking niet alleen afhangt van de logische juistheid van berekeningen, maar ook van de tijd waarin deze berekeningen worden uitgevoerd. Dat wil zeggen, voor gebeurtenissen die in een dergelijk systeem plaatsvinden, is het moment waarop deze gebeurtenissen plaatsvinden net zo belangrijk als de logische juistheid van de gebeurtenissen zelf.

Realtime systeemcomponenten.

Applicatiesoftware		verzending
		Inter-streaming interactie
Realtime besturingssysteem		Afhandeling onderbreken
	Prioriteit inversiebescherming	Stroomregeling
		Geheugen management
Hardware			Apparaten

Mac OS X-decodering:

"Mac" verwijst naar de naam van het Macintosh-bedrijf.

"OS" - besturingssysteem, dat wil zeggen, het besturingssysteem.

"X" - Romeins cijfer tien, betekent het versienummer van het besturingssysteem.

Ontwikkeling van moderne besturingssystemen

Bij de ontwikkeling van moderne besturingssystemen is er een tendens om de code verder naar de hogere niveaus te verplaatsen en alles wat mogelijk is uit de kernelmodus te verwijderen, waardoor er een minimale microkernel overblijft. Dit wordt meestal gedaan door de meeste taken van het besturingssysteem te verplaatsen naar gebruikersprocessen.

Wanneer een gebruikersproces (nu een serviceproces of clientproces genoemd) een verzoek voor een bewerking ontvangt, zoals het lezen van een blok van een bestand, stuurt het het verzoek naar het serverproces (serviceproces), dat het verwerkt en een reactie terugstuurt .

Door het besturingssysteem op te delen in delen, die elk slechts één element van het systeem beheren (bestandssysteem, processen, terminal of geheugen), zijn alle delen klein en beheersbaar.

Bovendien hebben alle servers geen directe toegang tot hardware, aangezien alle servers in de gebruikersmodus draaien in plaats van in de kernelmodus. Daarom, als er een fout optreedt op de bestandsserver, kan de bestandsaanvraagservice crashen, maar dit brengt meestal niet de hele machine tot stilstand.

Een ander voordeel van het client-servermodel is de gemakkelijke aanpassing voor gebruik in gedistribueerde systemen. Als een client met een server communiceert door er berichten naar te sturen, hoeft de client niet te weten of het bericht lokaal op zijn eigen machine wordt verwerkt of dat het via het netwerk naar een server op een externe machine is verzonden. Vanuit het oogpunt van de klant gebeurt in beide gevallen hetzelfde: er is een verzoek verzonden en een reactie ontvangen.

Het verhaal hierboven over de kernel die de berichtenstroom van clients naar servers en terug afhandelt, is niet helemaal realistisch. Sommige functies van het besturingssysteem, zoals het laden van instructies in fysieke I/O-registers, zijn moeilijk, zo niet onmogelijk, uit te voeren vanuit programma's in de gebruikersruimte. Er zijn twee manieren om dit probleem op te lossen.

De eerste is dat sommige kritieke serverprocessen (zoals I / O-apparaatstuurprogramma's) daadwerkelijk in de kernelmodus worden uitgevoerd, met: volledige toegang naar hardware, maar communiceren met andere processen via het gebruikelijke berichtenschema.

De tweede manier is om een minimaal informatieverwerkingsmechanisme in de kernel te bouwen, maar de politieke besluitvorming over te laten aan de servers in de gebruikersruimte. De kernel kan bijvoorbeeld berichten herkennen die naar specifieke adressen zijn verzonden. Voor de kernel betekent dit dat je de inhoud van het bericht moet nemen en het bijvoorbeeld in de I / O-registers van een schijf moet laden om een schijfleesbewerking te starten.

In dit voorbeeld zou de kernel de berichtbytes misschien niet eens kunnen onderzoeken als ze geldig of zinvol waren; het kan ze blindelings naar schijfregisters kopiëren. (Het is duidelijk dat er een schema moet worden gebruikt om de reeks processen te beperken die dergelijke berichten mogen verzenden).

De huidige staat van het onderwerpgebied

Verenigingen, bedrijven en producten

Microsoft en Apple Inc. zijn de meest populaire fabrikanten van besturingssystemen en software voor hen in de moderne wereld.

Moderne besturingssystemen van Microsoft:

Windows XP (Windows NT 5.1)

Windows Vista (Windows NT 6.0)

Windows 7 (Windows NT 6.1)

Windows 8 (Windows NT 6.2)

Windows 10 (Windows NT 10)

Moderne besturingssystemen van Apple Inc:

Moderne mobiele besturingssystemen:

Linux-systemen (Android)

Verschillen met besturingssystemen voor algemeen gebruik

Het belangrijkste verschil tussen de kerndiensten van RTOS is de deterministische aard van hun werk op basis van strikte tijdscontrole. In dit geval betekent determinisme dat de uitvoering van één service van het besturingssysteem een tijdsinterval van bekende duur vereist. Theoretisch kan deze tijd worden berekend met behulp van wiskundige formules, die strikt algebraïsch moeten zijn en geen tijdelijke parameters van willekeurige aard mogen bevatten. Elke willekeurige variabele die de uitvoeringstijd van een taak in een RTOS bepaalt, kan een ongewenste vertraging in de applicatie veroorzaken, dan past de volgende taak niet in zijn tijdschijf, wat een fout veroorzaakt.

In die zin zijn besturingssystemen voor algemene doeleinden niet deterministisch. Hun diensten kunnen willekeurige vertragingen in hun werk tolereren, wat kan leiden tot een vertraging in de reactie van de applicatie op gebruikersacties op een duidelijk onbekend tijdstip. Bij het ontwerpen van conventionele besturingssystemen richten ontwikkelaars zich niet op het wiskundige apparaat voor het berekenen van de uitvoeringstijd van een specifieke taak en service. Dit is niet kritisch voor dit soort systemen.

RTOS-architectuur

Tijdens zijn geschiedenis heeft de architectuur van besturingssystemen een aanzienlijke ontwikkeling doorgemaakt. Een van de eerste bouwprincipes, de zogenaamde. monolithische OS (Figuur 1), was om het OS weer te geven als een set modules die op verschillende manieren met elkaar interageren binnen de systeemkernel en applicatieprogramma's voorzien van invoerinterfaces voor toegang tot de hardware. Het belangrijkste nadeel van deze architectuur is de slechte voorspelbaarheid van het gedrag, veroorzaakt door de complexe interactie van systeemmodules met elkaar.

De meeste moderne besturingssystemen, zowel realtime als voor algemeen gebruik, zijn echter op dit principe gebouwd.

Bij automatiseringstaken worden gelaagde besturingssystemen veel gebruikt als RTOS (Afbeelding 2). Het bekende MS-DOS-systeem is een voorbeeld van zo'n OS. In systemen van deze klasse konden applicatietoepassingen niet alleen toegang krijgen tot hardware via de systeemkernel of zijn residente services, maar ook rechtstreeks. RTOS is jarenlang op dit principe gebouwd. Vergeleken met monolithische besturingssystemen biedt deze architectuur een veel grotere mate van voorspelbaarheid van systeemreacties en stelt applicatietoepassingen ook in staat snel toegang te krijgen tot hardware. Het nadeel van dergelijke systemen is het ontbreken van multitasking. In deze architectuur werd het probleem van het verwerken van asynchrone gebeurtenissen teruggebracht tot het bufferen van berichten en het vervolgens opeenvolgend pollen van de buffers en verwerking. Tegelijkertijd werd de naleving van de kritische servicevoorwaarden verzekerd door de hoge snelheid van het rekencomplex in vergelijking met de snelheid van externe processen.

Een van de meest effectieve architecturen voor het bouwen van realtime besturingssystemen is de client-server-architectuur. Algemeen schema Een besturingssysteem dat met deze technologie werkt, wordt weergegeven in figuur 3. Het belangrijkste principe van een dergelijke architectuur is om OS-services in de vorm van servers naar het gebruikersniveau te brengen, en de microkernel vervult de functies van een berichtverzender tussen clientgebruikersprogramma's en servers - systeemdiensten... Deze architectuur biedt veel voordelen op het gebied van vereisten voor RTOS en embedded systemen. Deze voordelen omvatten:

1. De betrouwbaarheid van het besturingssysteem neemt toe, aangezien elke service is in feite een op zichzelf staande applicatie en het is gemakkelijker om fouten te debuggen en op te sporen.

2. Zo'n systeem schaalt beter, omdat onnodige diensten kan worden uitgesloten van het systeem zonder de prestaties te beïnvloeden.

3. Verhoogt de fouttolerantie van het systeem, omdat: Een bevroren service kan opnieuw worden gestart zonder het systeem opnieuw op te starten.

Helaas worden tegenwoordig niet veel besturingssystemen op client-serverbasis geïmplementeerd. Tot de bekende RTOS-implementerende microkernel-architectuur behoren OS9 en QNX.

Soorten taken

Elk proces bevat een of meer taken. Het besturingssysteem zorgt ervoor dat een taak nieuwe taken kan voortbrengen. Taken in hun manier van handelen kunnen worden onderverdeeld in 3 categorieën.

1. Cyclische taken. Typisch voor besturings- en interactieve processen.

2. Periodieke taken. Typisch voor velen technologische processen en synchronisatietaken.

3. Impulstaken. Typisch voor signaleringstaken en asynchrone technologische processen.

De vijf belangrijkste onzichtbare taken van het besturingssysteem

1. Biedt hardware-software "grip"

Het besturingssysteem dient als een soort "vertaler" tussen de hardware van de computer en zijn software... Als je de computerkast opent, zie je verschillende borden, chips, kabels en andere componenten. Het is de fysieke basis die de uitvoering van het programma mogelijk maakt. Maar het programma kan niet zomaar de hardwarebronnen van de computer overnemen en gebruiken. Het doet dit via het besturingssysteem.

De laatste tijd worden besturingssystemen steeds vaker 'platforms' genoemd. En deze naam geeft heel nauwkeurig de essentie weer. Het besturingssysteem is het platform waarop de programma's zich bevinden. Of, zoals ze nu zeggen, toepassingen op het besturingssysteem. Het is het besturingssysteem waarmee de software kan "communiceren" met de hardware. Dit geldt ook voor invoer- en uitvoerapparaten. Het meest eenvoudig voorbeeld het invoerapparaat is het toetsenbord en het uitvoerapparaat is de monitor.

Dit is erg belangrijk werk... Theoretisch, honderden verschillende apparaten input en output. Laten we nemen gewone muis... Maar "muis" is een algemeen begrip. Er zijn tientallen verschillende modellen van deze manipulator. Het zou een ontmoedigende taak zijn om voor elk type muis afzonderlijke softwareondersteuning te bieden, zodat deze rechtstreeks "communiceert" met de bronnen van de computer. Maar de output is de driverbasis in het besturingssysteem. Voor de gebruiker lijkt het alsof hij zomaar een muis op zijn computer heeft aangesloten, en ze pakte hem meteen aan en begon te werken.

2. Laat dezelfde applicatie op verschillende hardware draaien

Het is het besturingssysteem waarmee de software op verschillende computers kan worden uitgevoerd, niet slechts op één specifieke configuratie. Er waren eens programma's geschreven voor een specifiek computermodel. De programmeertaal speelde eigenlijk de rol van het besturingssysteem van de voorlopers van moderne pc's, microcomputers van eind jaren zeventig van de vorige eeuw.

Maar tegenwoordig heeft het besturingssysteem de rol van een soort "adapter" tussen programma's en computerhardware op zich genomen. Als we twee computermodellen nemen, zullen de sets componenten waaruit ze zijn samengesteld verschillen. Dit geldt zelfs voor de bekende "Macintosh" die bekend staat om hun onderlinge gelijkenis, om nog maar te zwijgen van de enorme variëteit die te vinden is op de moderne pc-markt.

De besturingsomgeving creëert een zogenaamde abstracte omgeving voor het programma. Dit kan worden gezien als een dialoog tussen het besturingssysteem en het programma. Tijdens dit "gesprek" dat voor een persoon onbegrijpelijk is, "vertelt" het programma het platform over zijn behoeften en moet het besturingssysteem "denken" over hoe het rationeel aan deze behoeften kan voldoen. Het punt is dat je heel snel moet denken. De moderne gamer is niet klaar om een uur of twee te wachten voordat zijn favoriete game is geladen.

Het programma "vertelt" het besturingssysteem dus wat het precies nodig heeft om correct te werken. De applicatie is immers direct onbekend met de middelen van een computer. En het besturingssysteem verdeelt op zijn beurt de taken die eraan zijn toegewezen door het programma tussen de bronnen van het digitale apparaat. en het type hardware maakt voor het programma niet uit. Het platform regelt alles! Het besturingssysteem kan "praten", zo niet met alle, dan met heel veel apparaten en hardwaremodules.

Zonder deze waardevolle vaardigheid van het besturingssysteem zouden programmeurs hun programma's moeten herschrijven voor elke specifieke configuratie van de computer, voor elke set componenten. En als het niet voor het besturingssysteem is, werkt het programma misschien helemaal niet op een computer, waarvan de kenmerken verschillen van die door de programmeur bij het maken van het programma.

Ontwikkelaars bouwen tegenwoordig hun applicaties voor platforms, niet voor een bekende hardwareconfiguratie. Simpel gezegd, niet voor een specifieke computer, maar voor een specifiek besturingssysteem. Dit is natuurlijk veel makkelijker. Miljoenen apparaten kunnen op hetzelfde besturingssysteem draaien. Daarom zijn tien- en zelfs honderdduizenden toepassingen mogelijk geworden, beschikbaar voor de moderne gebruiker van elk van de populaire platforms.

3. Zoek naar het bestand dat vereist is voor de toepassing

De fysieke middelen van een computer alleen zouden niet voldoende zijn voor programma's om hun taken correct uit te voeren. Alle informatie wordt opgeslagen in bestanden en deze bestanden moeten aan bepaalde regels voldoen. Deze regels hebben betrekking op het benoemen en opslaan van bestanden. We noemen deze algemene set regels het "bestandsbeheersysteem" of gewoon "bestandsbeheer".

Verschillende besturingssystemen hanteren verschillende benaderingen voor het beheren van bestanden. Bovendien kan de gebruiker extra software installeren waarmee hij bestanden efficiënter kan beheren. Het is het besturingssysteem dat de bestanden "onthoudt" die op de computer zijn opgeslagen. Wanneer een toepassing toegang wil tot een bepaald bestand, wijst het besturingssysteem het programma de weg ernaartoe.

Zonder een bestandsbeheersysteem is digitale informatie op een computer slechts een zinloze verzameling gegevens. Een chaos waarin niets te vinden is. En nog meer om in de kortste fractie van een seconde te vinden.

Het besturingssysteem volgt onzichtbaar zijn regels, zodat u niet handmatig die geheugencellen hoeft te openen waar het bestand dat u nodig heeft fysiek is opgeslagen. Maar het belangrijkste is dat de gebruiker van een modern besturingssysteem deze regels niet hoeft te kennen om op een computer te kunnen werken.

4. Efficiënte toewijzing van beschikbaar RAM-geheugen

Aangezien we het over geheugen hebben, is het logisch om te onthouden over RAM (RAM, RAM). Over de opslag die altijd "bij de hand" is door de processor.

Benadrukt moet worden dat het besturingssysteem ook deze belangrijkste computerbron beheert. RAM is een sterk onderschatte bron door veel gebruikers. Hoe u uw computer sneller kunt laten werken? Velen geloven dat ze dringend meer nodig hebben krachtige processor... Maar in de praktijk is het vaak voldoende om simpelweg de hoeveelheid RAM te vergroten om een significante verbetering van de computerprestaties te voelen.

In RAM plaatst de computer de informatie die nodig kan zijn voor de processor die de berekeningen uitvoert. Beschouw dit type geheugen eenvoudig als een tijdelijke opslag van informatie die "dichter bij de processor" zou moeten zijn.

Als we met een computer werken, hebben we soms meerdere programma's tegelijk draaien. Het besturingssysteem wijst een bepaalde hoeveelheid geheugen toe aan elke taak. Als de processor informatie nodig heeft die hij niet in het RAM kan vinden, zal hij ergens anders moeten zoeken. Met name op de harde schijf van de computer. Het duurt langer dan het extraheren van gegevens uit het RAM. Voor de gebruiker zal deze situatie eruitzien als een tijdelijke "bevriezing" van de applicatie. In dergelijke gevallen is het gebruikelijk om te zeggen dat 'de computer denkt'.

Een van de taken die het besturingssysteem onzichtbaar voor de gebruiker op zich neemt, is het minimaliseren van de latentietijd, dat wil zeggen de zeer onaangename tijd waarin de computer bezig is met zijn eigen zaken en niet reageert op uw oproepen. Het probleem is dat op elk moment het besturingssysteem

heeft een bepaalde hoeveelheid RAM, die altijd beperkt is. Dit bedrag is onder andere afhankelijk van hoeveel programma's je tegelijkertijd hebt opgestart. Het besturingssysteem moet op elk moment "weten" hoeveel RAM het nog in voorraad heeft om het op tijd toe te wijzen aan een proces dat deze belangrijke hulpbron nodig heeft.

Het besturingssysteem "evalueert" de vereisten van elk lopend proces en beslist hoe hieraan redelijkerwijs kan worden voldaan. Idealiter zou dit zo moeten gebeuren dat de gebruiker helemaal geen vertraging ervaart. Maar in de praktijk probeert het besturingssysteem dergelijke vertragingen eenvoudig tot een minimum te beperken door de middelen die het daadwerkelijk heeft rationeel toe te wijzen.

Er zijn geen computers op aarde met onbeperkt RAM. Het systeem moet daarom altijd kiezen welk proces op een bepaald moment als prioriteit wordt beschouwd en welk proces secundair is. Aan wie het dringend is om geheugen toe te wijzen, en wie het voorlopig zal volhouden en geduldig zal zijn. De gebruiker is het mogelijk niet altijd eens met de regels die gelden voor het besturingssysteem bij het toewijzen van geheugen. Maar het zou veel moeilijker en langer zijn om onafhankelijk RAM-geheugen toe te wijzen aan processen dan om het aan het softwareplatform toe te vertrouwen.

5. Vestigt de aandacht van de processor op een bepaalde taak

De centrale verwerkingseenheid (CPU) is de fysieke module die de taken oplost die de gebruiker voor zijn computer instelt. Een ander ding is dat een zeldzame gebruiker de taal spreekt die de processor verstaat. Wat is er, zelfs niet elke programmeur is bekend met machinecode. Een persoon denkt misschien niet eens na over het feit dat een programma een complexe reeks wiskundige problemen is.

De centrale processor doet de berekeningen, dat wil zeggen, hij vindt een oplossing voor deze problemen, en het geeft je kant-en-klare resultaten die niet eens in de buurt komen van de formules uit het algebrahandboek. De gemiddelde gebruiker is gewoon niet geïnteresseerd in al deze wiskunde. Hij wil dat zijn speelbare personage in een fractie van een seconde over een obstakel springt, of hij wil de spelling controleren van de tekst die hij zojuist heeft geschreven. Achter deze schijnbaar verre van saaie getallen gaat de meest complexe wiskunde schuil.

Elk programma dat draait, vereist een fractie van de rekenkracht van de processor. Hoe meer programma's u tegelijkertijd draait, hoe dichter de CPU-belasting bij het maximum komt. De taak van het besturingssysteem is om de aanlevering van informatie voor verwerking aan de processor te coördineren, zodat alles soepel en onzichtbaar voor de gebruiker verloopt. Het besturingssysteem kan de aandacht van de processor van de ene taak naar de andere verplaatsen.

Een van de belangrijke rollen besturingssysteem is de rol van de resource manager. Als het deze taak goed aankan, weten we niet eens op welk moment de processor de ene taak opzij zette en zijn aandacht op de andere richtte.

Onzichtbare en onvervangbare assistent

De moeilijkste van alle taken voor een besturingssysteem is om het te negeren en je te concentreren op de applicaties die je interesseren. En terwijl alles goed gaat, denkt de gebruiker helemaal niet aan het platform. En pas wanneer softwarefouten beginnen, realiseert de gebruiker zich hoe belangrijk de missie van het besturingssysteem is.

Die "verschillen" tussen besturingssystemen die voor de meeste gebruikers merkbaar zijn, zijn puur cosmetisch. Het komt zelden voor dat een gebruiker de programmering voldoende begrijpt om achter de schil van een grafische interface te zien wat het ene besturingssysteem daadwerkelijk van het andere onderscheidt. Nee verschijning desktop- of app-pictogramontwerp heeft niets te maken met de intrinsieke aard van het besturingssysteem.

De hierboven beschreven taken worden op de een of andere manier door elk uitgevoerd modern besturingssysteem die elk computerapparaat bestuurt. Ongeacht hoe het besturingssysteem eruitziet en op welk apparaat het is geïnstalleerd: op een pc, mobiel apparaat of gameconsole.

Eigenaardigheden

Positieve eigenschappen

Wijdverbreide productdistributie

In de overgrote meerderheid van de gevallen is Windows OS op computers geïnstalleerd. Daarom kunt u, als u een vriend of uw werk bezoekt, eenvoudig een paar foto's van een flashstation overbrengen, tekstbestanden of clips. Gebruiksgemak en ondersteuning voor Windows OC van alle hardware en software die hebben bijgedragen aan de wereldwijde distributie van deze OC.

Leuke interface

Moderne OC's hebben een mooie en eenvoudige interface. Dit draagt bij aan het snel waarnemen van informatie, gebruiksgemak van de computer, snel leren werken met het besturingssysteem.

OS-stabiliteit

Over het algemeen is de stabiliteit van de moderne OC acceptabel te noemen. Het woord "aanvaardbaar" moet hier echter vergezeld gaan van een groot aantal kwalificaties:

1. Aanvaardbare stabiliteit van het besturingssysteem wordt pas na zijn hoge kwaliteit en competente instelling- het is niet de moeite waard om hier te praten over een niet-gestemd systeem (evenals een niet-gestemde gitaar).

2. De stabiliteit van een modern besturingssysteem hangt ook grotendeels af van de versie van het product en de aanwezigheid van geïnstalleerde servicepacks en add-ons - helaas, zonder hun aanwezigheid crasht het besturingssysteem vaak.

3. De stabiliteit van het besturingssysteem hangt ook af van de applicaties zelf die door de gebruiker op het besturingssysteem zijn geïnstalleerd: hoe stabieler ze in gebruik zijn en hoe beter compatibel met de software zelf. Windows-shell, hoe minder storingen we zullen kunnen waarnemen in de werking van het hoofdbesturingssysteem.

4. De stabiliteit van het moderne besturingssysteem wordt sterk beïnvloed door de hardware zelf, die wordt gebruikt in combinatie met het draaiende besturingssysteem.

5. Ook op stabiel werk De huidige OC wordt niet in het minst beïnvloed door apparaatstuurprogramma's. Deze miniprogramma's zijn verantwoordelijk voor het koppelen van bepaalde software aan bepaalde hardware.

Goede compatibiliteit met producten van verschillende ontwikkelaars (ongeveerOC ramen)

Moderne OC is in staat om alle bestandstypen die in zijn vroege reïncarnaties verschenen, correct te begrijpen. Als we dezelfde bestandsextensies herinneren, wordt het duidelijk dat hun voorouder in feite hetzelfde primitieve en archaïsche besturingssysteem is, ooit gekocht van een externe ontwikkelaar en in gedachten gebracht door Microsoft - MS-DOS. Deze continuïteit van bestandsformaten loopt als een rode draad door alle versies van Windows, wat op zich al geweldig is.

Hallo, Haber!
Vandaag vertel ik je hierover interessant ding als een realtime besturingssysteem (RTOS). Ik weet niet zeker of het interessant zal zijn voor ervaren programmeurs, maar ik denk dat beginners het leuk zullen vinden.

Wat is een RTOS?

Als we naar Wikipedia kijken, zien we maar liefst 4 definities.
Kortom, een RTOS is een besturingssysteem dat binnen een bepaalde tijdsperiode reageert op externe gebeurtenissen. Daarom begrijpen we het hoofddoel van een RTOS - apparaten waarbij een snelle reactie op gebeurtenissen vereist is (maar in geen geval mag de werking van een RTOS worden verward met interrupts).

Waarom hebben we het nodig?

Daar zijn nogal wat redenen voor.
Ten eerste ondersteunt de RTOS multitasking, procesprioriteiten, semaforen en meer.
Ten tweede is het zeer licht van gewicht en vereist het bijna geen middelen.
Ten derde kunnen we al het bovenstaande op bijna elke hardware krijgen (FreeRTOS werkt bijvoorbeeld zelfs op 8-bit AtMega).
En ten vierde: gewoon spelen en plezier hebben.

Review van 3 bekende RTOS.

Let op: wat volgt is mijn persoonlijke mening.

FreeRTOS

Een van de meest populaire RTOS van vandaag. Geporteerd naar een enorme hoeveelheid ijzer. Officiële site.

voordelen

1) Gratis
2) Geporteerd naar een grote hoeveelheid ijzer
3) Krachtige functionaliteit
4) Er zijn verschillende bibliotheken: afbeeldingen, internet en meer.
5) Goede documentatie.

minpuntjes

1) Vrijwel moeilijk proces overzetten naar nieuwe hardware.

Conclusie: dit is een echt professionele RTOS met goede documentatie. Het is goed voor een beginner als er al een poort op zijn hardware zit.

KeilRTX

Deze RTOS was tot voor kort commercieel, maar is sinds kort opengesteld. Werkt alleen op armarchitectuur. Officiële site.

voordelen

1) Gratis
2) Gemakkelijk over te zetten naar nieuwe hardware (binnen de armarchitectuur).
3) Er zijn verschillende bibliotheken: afbeeldingen, internet en meer.

minpuntjes

1) Met haar voor Keil werken is bijna onmogelijk
2) Iets uitgeklede functionaliteit
3) Alleen arm wordt ondersteund.
4) (uit persoonlijke ervaring) Verliest aan veel RTOS in snelheid.
Conclusie: ideaal voor beginners en kleine projecten.

uc / os

Krachtige commerciële RTOS. Website .

voordelen

1) Een enorm aantal functies en bibliotheken.
2) Ondersteunt veel ijzer

minpuntjes

1) Commercieel.
2) Moeilijk te gebruiken.

Conclusie: het is te ver om het een RTOS te noemen voor een beginner.

Andere interessante RTOS

RTLinux Een RTOS gebaseerd op reguliere Linux.
QNX RTOS gebaseerd op Unix.

Kenmerken van ontwikkeling met RTOS

Welnu, allereerst moet u het volgende begrijpen: RTOS is geen Windows. Het kan niet worden geïnstalleerd. Dit systeem wordt eenvoudig met uw programma gecompileerd.
Bij het schrijven van programma's met RTOS worden functies in hun gebruikelijke betekenis niet gebruikt. Processen (of taken) worden gebruikt in plaats van functies. Het verschil is dat processen, in tegenstelling tot functies, eindeloze cycli en nooit eindigen (tenzij iemand of hij hem zelf doodt - dat wil zeggen, hem uit zijn geheugen haalt).
Als er meerdere processen zijn ingeschakeld, schakelt de RTOS ze om, waarbij de machinetijd en bronnen één voor één worden weergegeven. Dit is waar het concept van procesprioriteit ontstaat - als twee processen tegelijkertijd machinetijd nodig hebben, dan zal de RTOS deze geven aan degene met de hogere prioriteit.
RTOS heeft speciale functies vertragingen - zodat er geen tijd wordt verspild tijdens de vertraging van het ene proces, wordt het tweede uitgevoerd.
Laten we het nu hebben over zoiets als een semafoor - dit is iets dat de toegang van een proces tot applicatiebronnen regelt. Voor elke resource is er een markering - wanneer een proces een resource nodig heeft, neemt het deze en gebruikt deze resource. Als er geen marker is, moet het proces wachten tot het wordt geretourneerd. Ik zal een voorbeeld geven: verschillende processen sturen informatie over één UART. Als er geen semafoor was, zouden ze de bytes één voor één verzenden en het zou een puinhoop zijn. En dus nam het eerste proces de markering op de UART, stuurde een bericht en gaf het aan de tweede (en zo verder - tot in het oneindige).

Extra RTOS-bibliotheken.

RTOS biedt vaak verschillende bibliotheken aan om bijvoorbeeld met afbeeldingen, internet etc. te werken. Ze zijn echt comfortabel en je moet niet aarzelen om ze te gebruiken. Onthoud echter dat ze zonder de RTOS waarvoor ze zijn geschreven niet zullen werken.
Hier zijn enkele voorbeelden:
Voor RTX