Samenvatting Besturingssystemen

Transcriptie

1 Samenvatting Besturingssystemen Vloeberghs Sam 2 Toegepaste Informatica

2 BESCHRIJVING EN BESTURING VAN PROCESSEN...4 WAT IS EEN PROCES?...4 Processen en besturingsblokken...4 PROCESTOESTANDEN...4 Creëren en beëindigen van processen...4 Procesmodel met 2 toestanden...5 Procesmodel met 5 toestanden...6 Redenen voor het opschorten van processen:...7 BESCHRIJVING VAN PROCESSEN...7 Beheersstructuren in het besturingssysteem...7 Beheersstructuren voor processen...7 PROCESBESTURING...9 Uitvoeringsmodi...9 Creëren van processen...9 Wisselen van processen...10 Uitvoering van het besturingssysteem...11 PROCESBEHEER IN UNIX SVR Procestoestanden...12 Beheer van processen...12 THREADS, SMP EN MICROKERNELS...14 PROCESSEN EN THREADS...14 Multithreading...14 Functionaliteiten van threads...15 Voorbeeld : Adobe Pagemaker...16 Threads op gebruikersniveau en op kernelniveau...16 Andere indelingen...17 SYMMETRISCHE MULTIPROCESSING...17 Architectuur van SMP...18 Ontwerpen van besturingssystemen voor SMP...19 MICROKERNELS...19 Architectuur van een microkernel...19 Voordelen van een microkernel...20 Prestaties van een microkernel...20 Ontwerp van een microkernel...21 BEHEER VAN THREADS EN SMP IN SOLARIS...22 Architectuur met multithreading...22 Motivering...23 Interrupts als threads...23 BEHEER VAN PROCESSEN EN THREADS IN LINUX...23 Taken in Linux...23 Threads in Linux...24 GELIJKTIJDIGHEID : WEDERZIJDSE UITSLUITING EN SYNCHRONISATIE...25 PRINCIPES VAN GELIJKTIJDIGHEID...25 Een eenvoudig voorbeeld...26 Aandachtspunten voor het besturingssysteem...27 Interactie van processen...27 Vereisten voor wederzijdse uitsluiting...28 WEDERZIJDSE UITSLUITING : HARDWAREONDERSTEUNING...28 Uitschakelen van interrupts...28 Speciale machine instructies...29 SEMAFOREN...30 Wederzijdse uitsluiting...31 Implementatie van semaforen...31 MONITOREN...31 Monitor met signal...32 GELIJKTIJDIGHEID : DEADLOCKS EN UITHONGERING...33

3 BEGINSELEN VAN DEADLOCK...33 Herbruikbare hulpbronnen...33 Verbruikbare hulpbronnen...33 Condities voor deadlock...34 VOORKOMEN VAN DEADLOCK...35 Wederzijdse uitsluiting...35 Vasthouden en wachten...35 Geen preëmptieve onderbreking...36 Cirkelvormig wachten...36 VERMIJDEN VAN DEADLOCK...36 Weigeren van een nieuw proces...37 Weigeren om bronnen toe te wijzen...37 DETECTEREN VAN DEADLOCK...38 Algoritmen voor detecteren deadlock...38 Herstel...39 GEÏNTEGREERDE AANPAK VAN DEADLOCK...39 PROBLEEM VAN DE DINERENDE FILOSOFEN...40 MECHANISMEN VOOR GELIJKTIJDIGHEID IN UNIX...41 Pijpen...41 Berichten...41 Gedeeld geheugen...41 Semaforen...41 Signalen...41 GEHEUGENBEHEER...42 VEREISTEN VOOR GEHEUGENBEHEER...42 Relocatie...42 Bescherming...43 Delen...43 Logische indeling...43 Fysieke indeling...43 PARTITIONEREN VAN GEHEUGEN...44 Vaste indeling van Partities...44 Dynamische indeling van partities...45 Buddysysteem...46 Relocatie...47 PAGINEREN...48 SEGMENTEREN...50 VIRTUEEL GEHEUGEN...51 HARDWARE EN BESTURINGSSTRUCTUREN...51 Lokaliteit en virtueel geheugen...51 Pagineren...52 Segmenteren...58 Gecombineerd pagineren en segmenteren...60 Bescherming en delen...60 BESTURINGSSYSTEEMSOFTWARE...61 Strategie bij ophalen (fetch policy )...61 Strategie bij plaatsing...61 Strategie bij vervanging...62 Beheer van de residente set...63 Opschoon strategie...66 Toezicht op de procesbelasting...66

4 Beschrijving en besturing van processen Wat is een proces? Processen en besturingsblokken We kunnen een proces voorstellen als een entiteit die bestaat uit een aantal elementen. Twee essentiële: 1. de programma code 2. verzameling van gegevens die bij de code hoort Een proces is gekenmerkt door een aantal elementen uit het procesbesturingsblok: o Identificatienummer o Toestand o Prioriteit o Programmateller o Geheugenwijzers o Contextgegevens o IO-toestandsinformatie o Beheersinformatie Het procesbesturingsblok moet voldoende informatie bevatten om een proces dat uitgevoerd wordt te kunnen onderbreken en op een later moment gewoon terug te kunnen starten alsof het nooit onderbroken werd. Het procesbesturingsblok is het belangrijkste hulpmiddel voor een besturingssysteem bij de ondersteuning van verschillende processen, waardoor multiprocessing mogelijk wordt. PROCES = PROGRAMMACODE & BIJHORENDE GEGEVENS + procesbesturingsblok Procestoestanden We kunnen het gedrag van een individueel proces beschrijven aan de hand van de volgorde van instructies die voor dat proces worden uitgevoerd: deze volgorde wordt een spoor ( trace ) van het proces genoemd. Er kunnen meerdere processen tegelijk uitgevoerd worden. De toedeler ( dispatcher ) wijst de processor wisselend toe aan de verschillende processen. De sporen van deze verschillende processen worden dus verweven Creëren en beëindigen van processen Creëren van processen Nieuwe batchtaak Interactieve aanmelding Gecreëerd door het besturingssysteem om een dienst te verzorgen Verwerkt door een bestaand proces Besturingssysteem ontvangt een jobbesturingsopdracht. Als het besturingssysteem bereid is de nieuwe taak uit te voeren, zal het de volgende reeks opdrachten lezen. Een gebruiker van het werkstation meld zich aan bij het systeem Het besturingssysteem kan een proces aanmaken om een bepaalde dienst af te werken waar de gebruiker om vraagt: bijvoorbeeld printen Een bestaand proces kan kind processen aanmaken die bepaalde bewerkingen afzonderlijk afwerken en het moederproces ondersteunen

5 Beëindigen van processen Normale voltooiing Tijdslimiet overschreden Onvoldoende geheugen beschikbaar Overtreding geheugengrens Beschermingsfout Rekenkundige fout Tijd verstreken I/O-fout Ongeldige instructie Geprivilegieerde instructie Onjuist gebruik van gegevens Ingreep van de gebruiker of het besturingssysteem Beëindiging van het ouderproces Verzoek van het ouderproces Proces roept een dienst aan om te melden dat uitvoering voltooid Proces wordt afgesloten omdat het zijn uitvoeringstijd heeft overschreden Proces probeert toegang te krijgen tot geheugenlocaties die niet voor hem bestemd zijn Het proces probeert iets te doen waar het geen rechten voor heeft, bijvoorbeeld schrijven naar een alleen-lezen bestand. Delen door nul, Het proces heeft langer gewacht op een gebeurtenis als aangegeven Er is een fout opgetreden bij de invoer of uitvoer van gegevens naar/van het proces Proces probeert instructie uit te voeren die niet bestaat Proces probeert gereserveerde instructie uit te voeren. De gegevens zijn mogelijk niet van het juiste type of zijn nog niet geinitialiseerd. De gebruiker of besturingssysteem roept een instructie aan om het proces te beëindigen Als het ouderproces beëindigt wordt, worden meestal ook de kindprocessen beindigd Het ouderproces kan verzoeken aan een kindproces om er mee te stoppen. Procesmodel met 2 toestanden

6 Procesmodel met 5 toestanden Actief ( running ) Gereed ( ready) Geblokkeerd ( blocked ) Nieuw ( new ) Einde ( exit ) Het proces dat op deze moment wordt uitgevoerd. In dit hoofdstuk gaan we uit van een single core processor => max 1 proces in deze toestand. Een proces dat direct kan worden uitgevoerd als het daar de gelegenheid voor krijgt. Een proces dat niet kan worden uitgevoerd totdat er zich een bepaalde gebeurtenis heeft afgespeeld. Een proces dat onlangs is aangemaakt maar zich nog niet in de ready state bevindt. Het is dus nog niet in het werkgeheugen geladen maar bevat al wel een procesbesturingsblok. Een proces dat door het besturingssysteem wordt ontslagen uit de groep uitvoerbare processen. Opgeschorte processen ( proces dat zich NIET in het hoofdgeheugen bevindt ) Soms is er het probleem dat de processor sneller is dan I/O dus alle processen kunnen wachten op I/O. De oplossing hiervoor is het swappen : dit is processen geheel of gedeeltelijk naar de schijf verplaatsen om hoofdgeheugen vrij te maken. Dit zorgt voor 2 nieuwe toestanden: Geblokkeerd opgeschort Gereed - opgeschort Het proces bevindt zich in het secundaire geheugen en wacht op een gebeurtenis Het proces bevindt zich in het secundaire geheugen maar is beschikbaar voor uitvoering zodra het in het hoofdgeheugen is geladen.

7 Redenen voor het opschorten van processen: Swapping Andere reden van het BS Verzoek van interactieve gebruiker Timing Verzoek van het ouderproces Het besturingssysteem moet voldoende hoofdgeheugen vrijmaken voor het binnenhalen van een proces dat gereed is om te worden uitgevoerd. Het besturingssysteem kan een achtergrond of hulpproces opschorten of een proces dat ervan wordt verdacht een probleem te veroorzaken Een gebruiker kan de uitvoering van een programma opschorten om fouten te zoeken of om een bron te gebruiken Een proces kan periodiek worden uitgevoerd ( bijvoorbeeld een proces voor administratie of systeembewaking ) en kan worden opgeschort terwijl wordt gewacht op de volgende tijdsinterval Een ouderproces kan de uitvoering van een kindproces opschorten om het te onderzoeken of te wijzigen. Beschrijving van processen Het besturingssysteem bestuurt gebeurtenissen binnen het computersysteem en verzorgt het inroosteren ( scheduling ) en de toedeling ( dispatching ) van processen voor uitvoering door de processor, wijst bronnen toe en reageert op vragen van gebruikersprogramma s. Besturingssysteem = Entiteit die het gebruik van systeembronnen door processen beheert Beheersstructuren in het besturingssysteem Het BS moet informatie bezitten over de huidige status van elk proces/bron. Het BS maakt en onderhoudt tabellen met informatie over elke entiteit die het beheert. Geheugentabellen - de toewijzing van hoofdgeheugen aan processen - de toewijzing van secundair geheugen aan processen - eventuele beschermingsattributen ( machtigingen v processen? ) - alle informatie die nodig is voor het beheren van het virtueel geheugen. I/O tabellen - informatie voor het beheren van I/O-kanalen en apparaten. Bestandstabellen - informatie over het bestaan van bestanden, locatie, status en andere attributen. Procestabellen - informatie voor het beheren van processen. ( volgende puntje ) - 1 entry per proces = bevat identificatie nummer vh proces. Beheersstructuren voor processen Proceslocatie De locatie van een procesbeeld is afhankelijk van het geheugenbeheersysteem dat wordt gebruikt. In het eenvoudigste geval wordt het procesbeeld bijgehouden als een aaneengesloten blok geheugen. Dit blok is opgeslagen in het secundaire geheugen, doorgaans op schijf. Het besturingssysteem moet dus de locatie van elk proces op schijf kennen en moet voor elk proces dat zich in het hoofdgeheugen bevindt, bovendien de locatie vh proces in het hoofdgeheugen kennen.

8 Procesbeeld: Gebruikersgegevens Gebruikersprogramma Systeemstack Procesbesturingsblok Het deel van de gebruikersruimte dat kan worden gewijzigd. Dit kan bestaan uit programmagegevens, een stackgebied voor de gebruiker en programma s die kunnen worden gewijzigd. Het uit te voeren programma Met elk proces zijn 1 of meer LIFO systeemstacks verbonden. Een stack wordt gebruikt voor het opslaan van parameters en aanroepadressen voor procedure- en systeemaanroepen. Gegevens die het besturingssysteem nodig heeft voor het beheren van het proces. Procesattributen We kunnen de informatie in het procesbesturingsblok groeperen tot drie algemene categorieën: Procesidentificatie - unieke numerieke identificatiecode - gebruikersidentificatiecode - ouderidentificatie Processortoestandsinformatie - Registers die zichtbaar zijn voor de gebruiker - Stuur- en statusregisters Programmateller Conditiecodes Statusinformatie - Stackwijzers Program Status Word ( PSW ) : Een register of een verzameling registers die statusinformatie bevat. Bvb: * EFLAGS register in Pentium Machines Procesbesturingsinformatie - Scheduling en toestandsinformatie Procestoestand Prioriteit Scheduling informatie Gebeurenis (code) - Gegevensstructuur - Communicatie tussen processen - Procesprivileges - Geheugenbeheer - Eigendom en gebruik van bronnen. Rol van het procesbesturingsblok Elke procesbesturingsblok bevat alle informatie die het BS nodig heeft. De verzameling van procesbesturingsblokken definieert de toestand van het besturingssysteem.

9 Procesbesturing Uitvoeringsmodi De meeste processors ondersteunen ten minste 2 uitvoeringsmodi: De gebruikersmodus : o Minder geprivilegieerd. Modus voor normale uitvoering van gebruikersprogramma s De systeem of kernel modus: o Meer privileges. Modus voor uitvoering van kernelfuncties ( IO, proces, geheugen beheer ) Standaardfuncties van de kernel van een BS: Procesbeheer Geheugenbeheer I/O-beheer Ondersteunende functies Creëren en beëindigen van processen Inroosteren en toedelen van processen Wisselen tussen processen Synchroniseren van processen + communicatie Beheren van PSB Toewijzen van adresruimte Swapping Beheren van pagina s en segmenten Beheren van buffers Toewijzen van IO-kanalen en apparaten aan processen Afhandelen van interrupts Administratie + toezicht De reden voor het gebruik van twee modi is dat het besturingssysteem en de belangrijkste tabellen moeten beschermd worden tegen verstoringen door gebruikersprogramma s. De processor weet in welke modus hij moet werken en naar welke modus hij moet veranderen door bepaalde bits in het PSW dat de uitvoeringsmodus aanduidt. Deze bits worden veranderd als reactie op bepaalde gebeurtenissen. Creëren van processen Als het besturingssysteem besloten heeft tot creatie van een nieuw proces dan kan het als volgt gaan: 1. Het BS wijst een unieke procesidentificatie toe aan het nieuwe proces a. Nieuwe ingang bij de primaire procestabel 2. Het BS wijst ruimte toe aan het proces a. Alle elementen van het procesbeeld 3. Het procesbesturingsblok moet worden geïnitialiseerd. a. 4. De juiste koppelingen moeten worden ingesteld 5. Soms moeten andere gegevenstructuren worden gemaakt of uitgebreid.

10 Wisselen van processen Wanneer moeten processen worden gewisseld Een proceswisseling kan steeds optreden wanneer het besturingssysteem de besturing heeft overgenomen van het proces dat op dit moment wordt uitgevoerd. Mechanismen voor het onderbreken van de procesuitvoering: Mechanisme Oorzaak Interrupt Extern aan de uitvoering van het huidige proces Val Verbonden aan de uitvoering van de huidige instructie Aanroep supervisor Expliciet verzoek Gebruik Reactie op een asynchrone externe gebeurtenis Afhandelen van een fout of een uitzonderlijke conditie Aanroep van een functie van het besturingssysteem Systeeminterrupts: Interrupt o Klokinterrupt Het besturingssysteem bepaald of het actieve proces de maximale toegestane uitvoeringstijd benut heeft. Zoja wordt er een ander proces geactiveerd. o I/O interrupt Is een I/O actie een gebeurtenis waarop één of meerdere processen wachten dan brengt het BS alle processen die hierop wachtten in de toestand Gereed, Gereed-opgeschort. o Geheugenfout De processor krijgt een verwijzing naar een woord adres dat zich niet in het hoofdgeheugen bevindt en zal het blok geheugen dat de verwijzing bevat naar het hoofdgeheugen moeten brengen. o Bij een val controleert het besturingssysteem of de fout al dan niet fataal is. Is deze fataal dan wordt het proces overgebracht naar de toestand Einde en treedt een proceswisseling op Val Supervisoraanroep Wisseling van modus Als er een interrupt wacht dan doet de processor het volgende: 1. De processor stelt de programmateller in op het beginadres van de routine voor de interruptafhandeling 2. De processor wisselt van gebruikersmodus naar kernelmodus, zodat de code voor de interruptverwerking geprivilegieerde instructies kan bevatten. De interruptafhandeling is meestal een kort programma dat enkele basistaken uitvoert die samenhangen met een interrupt. Het stelt bijvoorbeeld de vlag of indicator die de aanwezigheid van een interrupt signaleert, opnieuw in. In de meeste BS leidt het optreden van een interrupt echter niet noodzakelijk tot een proceswisseling. Het is mogelijk dat nadat de interruptafhandeling is uitgevoerd, de uitvoering van het actieve proces wordt voortgezet.

11 Wisseling van procestoestand Een volledig proceswisseling bestaat uit de volgende stappen: 1. Het opslaan van de context van het proces, inclusief de programmateller en andere registers 2. Het bijwerken van het PSB van het afgebroken proces 3. Het verplaatsen van het betreffende PSB naar de juiste wachtrij ( gereed, geblokkeerd,.. ) 4. Het selecteren van een ander uit te voeren proces. 5. Het bijwerken van het PSB van het geselecteerde proces 6. Het bijwerken van de gegevensstructuren voor het geheugenbeheer 7. Het terugbrengen van de context van dit proces naar de context zoals deze was op het moment dat het geselecteerd proces het laatst uit de toestand Actief werd gewisseld. Uitvoering van het besturingssysteem Het besturingssysteem werkt hetzelfde als gewone computersoftware: het is een programma dat wordt uitgevoerd door de processor. Het besturingssysteem geeft de besturing vaak uit handen en is voor het terugkrijgen ervan afhankelijk van de processor. Procesloze kernel De code van het besturingssysteem wordt uitgevoerd als een afzonderlijke entiteit die werkt in een geprivilegieerde modus Uitvoering binnen gebruikersprocessen Het uitvoeren van vrijwel alle software van het besturingssysteem in de context van een gebruikersproces. Hierbij wordt het besturingssysteem vooral gezien als een verzameling routines die het gebruikersproces aanroept voor het verzorgen van diverse functies die worden uitgevoerd binnen de omgeving van het gebruikersproces. Op processen gebaseerd besturingssysteem Het besturingssysteem wordt geïmplementeerd als een verzameling van systeem processen (modules). Er zijn duidelijke interfaces tussen de modules. De kernelsoftware wordt uitgevoerd in kernelmodus. Dit is een goede aanpak in multi-

12 Procesbeheer in UNIX SVR4 Procestoestanden User running Kernel running Ready to run, in memory Asleep in memory Ready to Run, swapped Sleeping, swapped Preempted Created Zombie Uitvoering in gebruikersmodus Uitvoering kernelmodus Gereed om te worden uitgevoerd zodra de kernel het proces inroosterd Kan niet worden uitgevoerd totdat een gebeurtenis optreedt; het proces bevindt zich in hoofdgeheugen ( geblokkeerd ) Het proces is gereed om te worden uitgevoerd, maar moet eerst naar het hoofdgeheugen worden geswapped. Het proces wacht op een gebeurtenis en is naar secundaire opslag geswapt. Het proces keert terug van kernel naar gebruikersmodus, maar de kernel onderbreekt het preemptief en voert een proceswisseling uit om een ander proces in te roosteren Het process is zojuist gecreëerd en is nog niet gereed om te worden uitgevoerd Het proces bestaat niet meer maar laat een record achter voor verwerking door ouderproces Beheer van processen In Unix wordt een proces gecreëerd met de systeemaanroep fork() in de kernel: 1. het wijst een positie ( slot ) in de procestabel toe aan het nieuwe proces 2. Het wijst een unieke procesidentificatiecode toe aan het kindproces 3. het maakt een kopie van het procesbeeld van de ouder 4. Het verhoogt de tellers voor alle bestande die in het bezit zijn van het ouderproces om aan te geven dat een extra proces deze bestanden nu ook in bezit heeft. 5. Het plaats het kindprocess in een toestand Ready to Run 6. Het geeft de identificatiecode van het kindproces terug aan het ouderproces en geeft waarde 0 aan het kindproces

13 Al deze bewerking worden uitgevoerd in kernelmodus bij het ouderproces. Als de kernel klaar is met deze functies, dan kan hij één van de volgende bewerking uitvoeren, als onderdeel van het toedelen: 1. In het ouder proces blijven. De besturing gaat terug naar de gebruikersmodus op het punt na de fork aanroep van ht ouderproces 2. De besturing overdragen aan het kindproces. De uitvoering van het kindproces begint op hetzelfde punt in de code als het ouderproces, namelijk bij de return van de fork aanroep 3. De besturing overdragen aan een ander proces.

14 Threads, SMP en Microkernels Processen en threads Tot nu toe hebben we 2 proceskenmerken besproken: 1. Bezit van bronnen a. Virtuele adresruimte wordt toegewezen voor de opslag van het procesbeeld 2. Inroosteren en uitvoering a. Een proces is een uitvoeringspad door één of meer programma s ( kan verweven worden ) In de meeste BS vormen deze kenmerken de kern van een proces. Ze worden onafhankelijk behandeld door het besturingssysteem. Onderscheid: Eenheid voor toedeling: thread of lichtgewicht proces Eenheid voor bronbezit: proces of taak Multithreading Het besturingssysteem ondersteunt de mogelijkheid meerdere threads te gebruiken bij de uitvoering van één proces. Voorbeelden: MS-DOS : 1 gebruikersproces,1 thread UNIX : meerdere gebruikersprocessen, 1 thread per proces WINDOWS : meerdere gebruikersprocessen, meerdere threads per proces In een multithreading omgeving wordt een proces gedefinieerd als een eenheid voor brontoewijzing en voor beveiliging. Het volgende is verbonden met processen: Virtuele adresruimte ( bevat het procesbeeld Beveiligde toegang tot processors, andere processen, bestanden en I/O-bronnen Een thread wordt gedefinieerd als een eenheid van uitvoering. Het volgende is verbonden met threads : Een uitvoeringstoestand ( Actief, Gereed, ) Context ( opgeslagen als de thread niet uitgevoerd wordt ) Uitvoeringsstack Statische opslagcapaciteit voor lokale variabelen per thread Toegang tot het geheugen en de bronnen van het bijhorende proces(gedeeld door alle threads)

15 De grootste voordelen van threads hangen samen met de gevolgen voor de prestaties: 1. Minder tijd nodig om een thread te creëren dan om een proces te starten 2. Minder tijd nodig om een thread te beëindigen dan om een proces te beëindigen. 3. Minder tijd nodig om over te schakelen tussen twee threads binnen het zelfde proces 4. een efficiëntere manier van communicatie tussen threads: gedeeld geheugen en bestanden. Dit zonder het activeren van de kernel Voorbeeld : De File Server Een nieuwe bestandsaanvraag = een nieuwe thread Een file server krijgt veel bestandsaanvragen : de communicatie loopt snel ( creatie en het beëindigen van de threads gaat snel ) Er is snelle en efficiënte communicatie nodig omdat de toegang tot de bestanden gecoördineerd moet worden : Het is sneller om threads te gebruiken i.p.v. processen die uitwisseling van berichten gebruiken. Nog enkele algemene voorbeelden : o Werk op de voorgrond en achtergrond - terwijl de gebruiker invoer geeft kan het programma deze invoer op de achtergrond verwerken ( opslaan, berekeningen maken, ) o Asynchrone verwerking - Bijvoorbeeld het geregeld wegschrijven van de RAM-buffer naar schijf om eventueel gegevensverlies te voorkomen o Uitvoeringssnelheid - 1 thread kan de volgende gegevens lezen, terwijl een andere thread de vorige gegevens verwerkt. o Modulaire programma structuur - Programma s met uiteenlopende activiteiten, verschillende bronnen/uitvoer hebben zijn met threads gemakkelijker te ontwerpen/implementeren Functionaliteiten van threads Sommige acties op het proces hebben invloed op ALLE threads van het proces: bijvoorbeeld: Opschorten : alle threads worden opgeschort. Beëindigen : alle threads worden beëindigt. Threadtoestanden Er zijn 4 basisbewerkingen met threads die samenhangen met een verandering van de threadtoestand : Verwekken Als een nieuw proces wordt verwerkt wordt er automatisch een nieuwe thread verwekt, welke op zijn beurt nieuwe threads kan opwekken. => Gereed voor uitvoering Blokkeren Als de thread moet wachten op gebeurtenis => Geblokkeerd Deblokkeren Optreden van gebeurtenis => Gereed voor uitvoering Beëindigen Thread voltooid : registercontext + stacks worden ongedaan gemaakt. Leidt het blokkeren van 1 thread tot het blokkeren van het volledige proces?

16 Synchronisatie van threads Alle threads van een proces delen dezelfde adresruimte en andere bronnen, zoals open bestanden. Een wijziging van een bron door een thread heeft invloed op de omgeving van de andere threads binnen hetzelfde proces. Daarom is het noodzakelijk de activiteiten van de verschillende threads te synchroniseren om te voorkomen dat ze elkaar storen of beschadigen. Voorbeeld : Adobe Pagemaker Zie boek Threads op gebruikersniveau en op kernelniveau Threads op gebruikersniveau Al het thread -beheer wordt uitgevoerd door de toepassing De kernel is zich niet bewust van het bestaan van threads. Elk proces heeft zijn threadbibliotheek : pakket van routines voor ULT-beheer Voordelen: Threadwisseling vereist geen privileges van kernel modus Schedulingsalgoritme kan aangepast worden zonder scheduler van het BS te moeten aanpassen ULT s kunnen uitgevoerd worden op elk BS : vereist geen aanpassing van onderliggende kernel. De Threadbibliotheek bevindt zich op toepassingsniveau. Nadelen: Als de ULT een systeemaanroep doet wordt de thread geblokkeerd + ook alle andere threads van hetzelfde proces Bij een zuivere ULT is er geen voordeel van multiprocessing. Scheduler wijst processor toe aan een proces : slecht 1 thread kan tegelijk uitgevoerd worden. Threads op kernelniveau Al het werk voor threadbeheer wordt uitgevoerd op kernelniveau Kernel houdt contet informatie bij voor de processen + alle threads binnen de processen Scheduling gebeurt op thread-basis

17 Voordelen: Kernel kan meerdere threads van het zelfde proces schedulen op meerdere processors Geblokkeerde thread blokkeert niet het ganse proces Nadelen: Moduswisseling is vereist : overhead Er is dus weliswaar een significante snelheidswinst bij het gebruik van multithreading met KLT s in plaats van processen met één thread, maar is de snelheidswinst nog groter bij het gebruik van ULT s. Gecombineerde benaderingen Thread reatie wordt op gebruikersniveau gedaan Grootste deel van de scheduling en de synchronisatie gebeurt binnen de toepassing. ULT s worden gekoppeld aan evenveel of minder KLT s Goed ontwerp : combinatie van voordelen van beide benaderingen Andere indelingen Threads : processen 1:1 M:1 1:M M:N Beschrijving Elke uitvoeringsthread is een uniek proces met een eigen adresruimte en bronnen Een proces definieert een adresruimte en dynamisch bezit van bronnen. Binnen het proces kunnen meerdere threads worden gecreëerd en uitgevoerd Een thread kan migreren van de ene naar de andere procesomgeving. Hierdoor kan een thread eenvoudig worden verplaatst tussen verschillende systemen Combineert de eigenschappen van de voorgaande gevallen Voorbeeldsystemen De oorspronkelijke implementaties van UNIX Windows NT, Solaris, Linux, OS/2, OS/3900 MACH Ra ( Clouds ), Emerald TRIX Symmetrische multiprocessing Traditioneel werd de computer bezien als een sequentiële machine. ( instructie per instructie, proces per proces, ) Naarmate de computertechnologie zich verder ontwikkelde en de kosten van de computerhardware daalden, hebben ontwerpers van computers gezocht nar steeds meer mogelijkheden voor parallelle verwerking, meestal om de prestaties te verbeteren en de vertrouwbaarheid te verhogen.

18 Architectuur van SMP Flynn onderscheidde de volgende computersystemen: SIMD-stroom ( single instruction, multiple data ) Één machine-instructie bestuurd de gelijktijdige uitvoering van een aantal verwerkingselementen in een vast patroon. Met elk verwerkingselement is een gegevensgeheugen verbonden zodat elke instructie door de verschillende processors wordt uitgevoerd met een andere verzameling gegevens. MISD-stroom ( multiple instruction, single data ) Een reeks gegevens wordt verzonden naar een verzameling processors, die elk een andere instructiereeks uitvoeren. ( nog nooit geïmplementeerd ) MIMD-stroom ( multiple instruction, multiple data ) Een verzameling processors voert tegelijk verschillende instructiereeksen uit met verschillende gegevensverzamelingen. MIMD- s kunnen verder worden onderverdeeld op basis van de wijze waarop hun processors communiceren. Hebben de processors elk een eigen geheugen, dan is elke processor een eigen computer. Geen gedeeld geheugen => onafhankelijke computers. De communicatie gebeurd via vaste paden of netwerkvoorzieningen = Cluster of MultiComputer LOOSELY COUPLED Gedeeld geheugen => Communicatie verloopt via dat geheugen. TIGHTLY COUPLED MASTER / SLAVE Kernel op 1 bepaalde processor, de andere processors voeren enkel gebruikersprogramma s uit. De master is verantwoordelijk voor het inroosteren van processen en threads. SMP ( symmetrische multiprocessor ) Bij een SMP kan de kernel op eender welke processor uitgevoerd worden. Elke processor zorgt voor de scheduling van zijn eigen threads en processen. Het ontwerp van SMP s en clusters is complex want men krijgt te maken met problemen zoals: o De fysieke organisatie o De structuur van onderliggende verbindingen o Communicatie tussen processors o Ontwerp van het BS o Technieken voor softwaretoepassingen

19 Ontwerpen van besturingssystemen voor SMP Een besturingssysteem voor SMP beheert de processors en andere computerbronnen op zo n manier dat de gebruiker het systeem op dezelfde wijze kan zijn als een systeem met één processor en multiprogrammering. De belangrijkste aandachtspunten voor het ontwerp zijn : Gelijktijdig samenwerkende processen of threads Bij meerdere processors die dezelfde/verschillende delen vd kernel uitvoeren, moet kerneltabellen en beheerstructuren goed worden beheerd om deadlocks en ongeldige bewerkingen te voorkomen Scheduling Conflicten moeten worden vermeden. Synchronisatie De synchronisatie is een voorziening die zorgt voor wederzijdse uitsluiting en het ordenen van gebeurtenissen. Een gebruikelijk mechanisme hiervoor zijn grendels ( locks ) Geheugenbeheer De pagineringmechanismen van verschillende processors moet worden gecoördineerd om consistentie te waarborgen wanneer verschillende processors een pagina / segment delen of besluiten een pagina te vervangen Betrouwbaarheid en fouttolerantie Microkernels Een microkernel is een kleine kern van een besturingssysteem die de basis vormt voor modulaire uitbreidingen. Dit is een vrij populair concept. Het begrip microkernel en zijn eigenschappen zijn vrij vaag: Hoe groot moet een microkernel zijn om microkernel te mogen heten? Moet de uitvoering ervan in kernel of gebruikersruimte plaatsvinden? Hoe moet het ontwerp gebeuren en wat moet er allemaal geïmplementeerd worden? Architectuur van een microkernel De eerste besturingssystemen van de jaren 50 waren monolithische besturingssystemen: Ze hadden geen structuur en waren onbeheersbaar Elke procedure kon bijna elke andere procedure aanroepen Later kwamen er gelaagde besturingssystemen : Met modulaire programmeertechnieken voor het beheersen van software ontwikkeling De meeste of alle lagen worden uitgevoerd in de kernelmodus Nadelen: o Veel interactie tussen aangrenzende lagen o Veranderingen hebben talrijke gevolgen o Beveiliging moeilijk in te bouwen

20 De filosofie achter een microkernel is dat alleen de essentiële kernfuncties van het besturingssysteem in de kernel zijn opgenomen. Vele diensten die traditioneel tot het BS horen zijn nu geïmplementeerd als externe subsystemen : o Apparaat stuur programma s ( Drivers ) o Bestandssystemen o Manager voor virtueel geheugen o Venstersysteem o Beveiligingsdiensten Voordelen van een microkernel o Uniforme interface bij verzoeken van een proces Processen hoeven geen onderscheid te maken tussen diensten op kernel en gebruikers niveau Alle diensten worden verleend via het uitwisselen van berichten o Uitbreidbaarheid Eenvoudig toevoegen van nieuwe diensten o Flexibiliteit Nieuwe voorzieningen kunnen gemakkelijk toegevoegd worden Bestaande voorzieningen kunnen gemakkelijk verwijderd worden o Overdraagbaarheid Alle processorspecifieke code bevindt zich in de microkernel: Veranderingen om een het BS aan te passen moet hier gebeuren en niet in andere diensten o Betrouwbaarheid Modulair ontwerp Kleine microkernel kan uitgebreid getest worden Beperkt aantal API s o Ondersteuning van gedistribueerde systemen Berichten worden verstuurd naar diensten : Een verzendend proces moet niet weten op welke machine de dienst zich bevindt o Ondersteuning voor objectgeoriënteerde besturingssystemen ( OOOS ) Componenten zijn objecten met duidelijk gedefinieerde interfaces, en die onderling verbonden kunnen worden om software te bouwen. Prestaties van een microkernel Een mogelijk nadeel van microkernel dat vaak genoemd wordt zijn de prestaties : Het opstellen en versturen van een bericht en het accepteren en decoderen het antwoord kost meer tijd dan het uitvoeren van 1 dienstaanroep. Veel is afhankelijk van de grootte en de functionaliteit van de microkernel.

21 Ontwerp van een microkernel Aangezien de functionaliteit en de grootte van verschillende microkernels variëren kunnen geen vaste regels worden opgesteld qua structuur en functionaliteiten. Hier lichten we de minimale verzameling van functies en diensten van de microkernel toe om de indruk te geven van het ontwerp van microkernels. Deze functies worden ingedeeld in de volgende 3 categorieën: Primitief geheugenbeheer De microkernel moet het hardware concept adresruimte ondersteunen om de implementatie van bescherming op procesniveau mogelijk te maken. Zolang de microkernel verantwoordelijk blijft voor het afbeelden van alle virtuele pagina s op fysieke pagainframes, kan het grootste deel van het geheugenbeheer worden geïmplementeerd buiten de kernel. 1. Thread in toepassing verwijst naar een pagina niet in het hoofdgeheugen. 2. Paginafout en uitvoering valt terug op kernel 3. Kernel stuurt bericht naar pagineerder met de aangeving naar welke pagina verwezen wordt. 4. Pagineerder kan besluiten de pagina te laden 5. Is de pagina eenmaal beschikbaar, dan stuurt de pagineerder een hervattingbericht naar de toepassing Communicatie tussen processen De elementaire vorm van communicatie tussen processen of threads in een BS met een microkernel is het bericht. Een bericht bestaat uit: Een kop : info over verzendende en ontvangende proces Een romp : directe gegevens, verwijzing naar een blok gegevens en/of besturingsinformatie Vaak kunnen we zeggen dat IPC ( Inter Proces Communication ) gebaseerd is op poorten die verbonden zijn met processen. Een poort is hier in wezen een wachtrij met berichten die bestemd zijn voor een bepaald proces ( een proces kan verschillende poorten hebben ) I/O en interruptbeheer Bij een microkernel architectuur is het mogelijk hardware-interrupts af te handelen als berichten en I/ O poorten op te nemen in adresruimten. De microkernel kan interrupts herkennen maar handelt ze niet af. In plaats daarvan genereert de microkernel een bericht voor het proces op gebruikersniveau dat op dit moment is verbonden met die interrupt. Is een interrupt ingeschakeld, dan is een bepaald proces op gebruikersniveau toegewezen aan de interrupt en onderhoudt de kernel de mapping. Het omzetten van interrupts in berichten moet worden uitgevoerd door microkernel maar de microkernels is niet betrokken bij de interruptafhandeling voor specifieke apparaten.

22 Beheer van threads en SMP in Solaris Solaris gebruikt een ongewone threadvoorziening met meerdere niveaus die ontworpen is met het oog op een hoge flexibiliteit bij het benutten van processorbronnen. Architectuur met multithreading Solaris gebruikt 4 afzonderlijke, aan threads verwante concepten: 1. Proces: normale UNIX proces, omvat de adresruimte, stack en procesbesturingsblok 2. Threads op gebruikersniveau : geïmplementeerd als een threadbibliotheek in de adresruimte van een proces 3. Lichtgewichtprocessen : Elk LWP ondersteund één of meer ULT s en is een afbeelding naar één kernelthread. 4. Kernelthreads : basisentiteiten die kunnen worden ingeroosterd en toegedeeld worden om te worden uitgevoerd op een van de processors van het systeem Deze figuur illustreert de relatie tussen deze 4 entiteiten. Er is precies 1 kernelthread voor elk LWP. Elke LWP is verbonden aan 1 toedeelbare kernelthread. Proces 1 bestaat uit één ULT die is gebonden aan één LWP. Proces 2 komt overéén met een zuivere ULT benadering. Alle ULT s worden ondersteund door 1 kernelthread en daardoor kan maar een ULT tegelijk uitgevoerd worden. Proces 3 toont meerdere threads die veelvoudig zijn verboden aan een kleiner aantal LWP s. Proces 4 heeft voor elke ULT een kernelthread Proces 5 toont een combinatie van 3 en 4

23 Motivering De combinatie van threads op gebruikersniveau en threads op kernelniveau biedt de programmeur van toepassingen de mogelijkheid gelijktijdigheid toe te passen op de wijze die het meest efficiënt en het meest geschikt is voor een bepaalde toepassing. Interrupts als threads De meeste besturingssystemen kennen twee basisvormen van asynchrone activiteit : processen en interrupts. Processen of threads werken met elkaar samen en beheren het gebruik van gedeelde gegevensstructuren door middel van verschillende primitieven die zorgen voor wederzijdse uitsluiting en die hun uitvoering synchroniseren. De reden voor het omzetten van interrupts in threads is het terugbrengen van de overhead. Dit zorgt voor een betere performantie. Oplossing in Solaris: 1. Solaris gebruikt verzameling Kernelthreads voor het afhandelen van interrupts. Zoals elke kernelthread heeft een Interruptthreads een eigen ID, prioriteit, context en stack 2. Voor het afhandelen van interrupts worden de gebruikelijke synchronisatie technieken voor threads gebruikt 3. Interruptthreads krijgen een hogere prioriteit dan alle andere Kernelthreads. Beheer van processen en threads in Linux Taken in Linux In Linux wordt een proces of taak weergegeven door een task_struct gegevensstructuur. Deze bevat informatie over een aantal onderwerpen: Toestand of status v/h proces ( Uitvoering, Gereed, geblokkeerd, opgeschort, zombie, ) Schedulinginformatie ( informatie nodig om processen in te roosteren ) Identificatiecodes : uniek ID per proces + ID voor gebruiker en groep Interprocescommunicatie Verwijzingen ( naar bijvoorbeeld ouder processen of zus-processen ) Tijden en klokken ( creatietijdstip + processortijd die al benut is door het proces ) Bestandssysteem : verwijzigen naar alle gerelateerde bestanden Adresruimte ( definieert de virtuele adresruimte die toegewezen is aan het proces ) Specifieke processorcontext : inhoud van de registers en stack

24 Bovenstaande figuur toon de uitvoeringstoestanden van een proces/thread in Linux : o o o o o Actief ( running ) In Uitvoering of Gereed Onderbreekbaar ( Interruptable ) Het proces wacht op een gebeurtenis Ononderbreekbaar ( Uninterruptable ) Het proces wacht op een hardwareconditie en zal op niets anders reageren Gestopt ( stopped ) Het proces is gestopt en kan alleen worden hervat wanneer een ander proces hiervoor actie onderneemt Zombie Het proces in geëindigd maar beschikt nog wel over zijn taakstructuur in de procestabel Threads in Linux Oudere Linux-versies: geen multithreading Geen onderscheid tussen threads en processen: threads op gebruikersniveau komen overeen met processen op kernelniveau Threads van eenzelfde gebruikersproces: zelfde groepsidentificatiecode op kernelniveau proces creëren: attributen van huidig proces kopiëren a.h.v. clone() fork() geïmplementeerd a.h.v. clone() traditionele fork() wordt geïmplementeerd als clone() met alle clone-vlaggen uit

25 Gelijktijdigheid : wederzijdse uitsluiting en synchronisatie De hoofdthemas van het ontwerp van besturingssystemen hangen alle samen met het beheer van processen en threads: Multirogrammering ( beheer van meerdere processen in een systeem met 1 processor ) Multiprocessing (het beheer van meerdere processen in een systeem met meerdere processors) Gedistribueerde verwerking ( beheer van meerdere processen op verschillende computersystemen ) Aan de basis van al deze zaken ligt gelijktijdigheid. Gelijktijdigheid treedt op in 3 situaties : o Meerdere toepassingen ( multiprogrammatie ) o Gestructureerde toepassing ( een applicatie kan geprogrammeerd worden als een verzameling gelijktijdige processen ) o Structuur vh BS ( kan ook beschouwd worden als een verzameling van processen of threads. ) Enkele belangrijke termen met betrekking tot gelijktijdigheid: Kritieke sectie Deadlock Livelock Wederzijdse uitsluiting Race-conditie Verhongering Een stuk programmacode binnen een proces waarvoor toegang tot gedeelde bronnen noodzakelijk is en dat mogelijk uitgevoerd wordt terwijl een ander proces in een corresponderend stuk programmacode uitgevoerd wordt. Een situatie waarin 2 of meer processen niet verder verwerkt kunnen worden omdat elk van de processen op een of meerdere andere wacht tot deze iets doen. Een situatie waarin 2 of meer processen continu hun toestand wijzigen als respons op veranderingen in het andere proces/de andere processen, zonder daarvoor enig werk van betekenis te doen. De eis dat wanneer een proces zich in kritieke toestand bevindt waarbij gedeelde bronnen gebruikt worden, geen van de andere processen zich in een kritieke sectie mag bevinden die gebruik kan maken van een of meerdere van de gedeelde bronnen. Een situatie waarin verschillende threads of processen een gedeeld gegeven lezen en schrijven en het uiteindelijke resultaat afhangt van de timing van de uitvoering van de lees- en schrijf bewerkingen. Een situatie waarin een uitvoerbaar proces eindeloos genegeerd wordt door de scheduler; het komt nooit aan de beurt hoewel het gereed is voor uitvoering. Principes van gelijktijdigheid Bij het verweven en overlappen van processen is er dezelfde problematiek : nl. de relatieve snelheid van uitvoering van processen kan niet voorspeld worden en dit brengt complicaties met zich mee zoals: o Het delen van bronnen kent tal van gevaren. ( tegelijke lees en schrijfbewerkingen kan de integriteit van gegevens in gevaar brengen o Het optimaal beheren van de toewijzing van deze bronnen is een uitdaging voor het besturingssysteem o Programmeerfouten zijn zeer lastig op te sporen omdat fouten niet reproduceerbaar zijn.

26 Een eenvoudig voorbeeld void echo () { chin = getchar(); chout = chin; putchar =(chout); } Dit programma toont de basiselementen voor de registratie en uitvoer van een toetsaanslag op het scherm. Het delen van hoofdgeheugen door processen is nuttig voor een efficiënte en sterke interactie tussen processen. Dit delen kan echter tot problemen leiden : 1. Proces 1 start echo() en wordt onderbroken net na getchar(). Het laatst ingevoerde teken, x, is in chin opgeslagen. 2. Proces 2 wordt geactiveerd en start echo() die volledig wordt uitgevoerd en de invoer en uitvoer van 1 teken, y, op het scherm weergeeft. 3. Proces 1 wordt hervat. Op dat moment is de waarde in chin overgeschreven en daarmee verloren gegaan. chin bevat nu de waarde, y, en voert deze dan ook uit. => De gedeelde globale variabelen ( en andere gedeelde bronnen ) moeten worden beschermd en dat dit alleen mogelijk is door het bewaken van de code die toegang heeft tot de variabele. Veronderstel nu het zelfde probleem maar dan bij een systeem met meerdere processors, die dezelfde procedure echo aanroepen en dat er geen mechanisme is voor het toegangsbeheer tot de gedeelde globale variabele. Proces P1. chin = getchar();. chout = chin; putchar(chout);.. Proces P2.. chin = getchar(); chout = chin;. putchar(chout);. Het resultaat is dat het voor P1 ingevoerde teken verloren gaat voordat het wordt weergegeven en zowel P1 als P2 geven het ingevoerde teken van P2 weer. Nu stellen we de regel in dat er maar 1 proces tegelijk toegang mag hebben tot het proces : 1. Proces P1 en P2 worden beide verwerkt op een afzonderlijke processor en beide roepen de procedure echo aan. 2. Terwijl P1 zich binnen de procedure echo bevindt roept P2 echo aan. Aagenzien P1 zich nog in de procedure echo bevindt, wordt de toegang van P2 tot de procedure geblokkeerd. P2 wordt daarom opgeschort. 3. Voltooit P1 de uitvoering van echo, dan verlaat het de procedure en wordt de uitvoering van P2 hervat en begint P2 met de uitvoering van echo Voorgaand voorbeeld was een race-conditie. Een race conditie onstaat wanneer verschillende processen of threads gegevensitems lezen en schrijven, waardoor het uiteindelijke resultaat afhankelijk is van de volgorde waarin de instructies in de verschillende processen worden uitgevoerd.

27 Aandachtspunten voor het besturingssysteem 1. Het besturingssysteem moet de verschillende actieve processen kunnen volgen. ( dit gebeurd door middel van de procesbesturingsblokken ) 2. Het besturingssysteem moet bronnen toewijzen en terug afnemen. Bronnen : a. Processortijd b. Geheugen c. Bestanden d. I/O-apparaten 3. Het besturingssysteem moet de gegevens en fysieke bronnen van elk proces beschermen tegen verstoringen door andere processen 4. Resultaat van een proces en de uitvoer ervan moet onafhankelijk zijn van de snelheid van de uitvoering ervan ten opzichte van de snelheid van andere concurrerende processen. Interactie van processen Mate van bewustzijn Processen zijn zich niet bewust van elkaar Processen zijn zich indirect bewust van elkaar ( gedeeld object) Processen zijn zich direct bewust van elkaar ( communicatie primitieven ) Relatie Invloed van proces op een ander proces o Resultaten van een proces zijn onafhankelijk van de actie van andere processen o Timing van proces kan beïnvloed zijn Samenwerking o Resultaten van een proces kunnen afhankelijk zijn van informatie van door delen andere processen. o Timing van proces kan beïnvloed zijn Concurrentie Samenwerking o Resultaten van een proces kunnen afhankelijk zijn van informatie van door andere processen. communicatie o Timing van proces kan beïnvloed Mogelijke besturings - problemen o Wederzijdse uitsluiting o Deadlock o Uithongering o Wederzijde uitsluiting o Deadlock o Uithongering o Gegevenssamenhang o Deadlock o uithongering zijn Concurrentie tussen processen om bronnen Er is behoefte aan wederzijdse uitsluiting. Er is een kritieke bron en een kritieke sectie. o Een kritieke bron is een niet deelbare bron: Bijvoorbeeld een printer. o Een kritieke sectie is een deel van programma dat de kritieke bron gebruikt ( slechts 1 programma tegelijk mag zich in zijn kritieke sectie bevinden ) Dit veroorzaakt twee andere besturingsproblemen : o Deadlock BS wijst Bron1 toe aan Proces2 en Bron2 aan Proces1. Elk proces wacht op een van de twee bronnen. Beide zullen de bron die al bezig is pas vrijgeven wanneer ook de andere bron in bezit gekomen is en vervolgens de functie waarvoor beide bronnen nodig was is uitgevoerd. o Starvation Dit gebeurd wanneer een proces constant genegeerd wordt alhoewel het gereed is om uit te voeren.

28 Samenwerking tussen processen door delen Aangezien gegevens toegankelijk zijn vanuit bronnen ( apparaten / geheugen ) spelen nu ook de beheersproblemen wederzijdse uitsluiting, deadlocks en uithongering een rol. Het enige verschil is dat gegevenselementen toegankelijk kunnen zijn in 2 verschillende modi ( lezen / schrijven ) en dat alleen het schrijven wederzijds uitgesloten hoeft te zijn. Naast deze problemen bestaat echter een nieuwe belangrijkere vereiste: gegevenssamenhang ( data coherence ) Samenwerking tussen processen door communiceren Werken processen samen door te communiceren, dan nemen de verschillende processen gezamenlijk deel aan een gemeenschappelijke inspanning, die alle processen verenigt. De communicatie is daarbij een middel om de verschillende activiteiten te synchroniseren of te coördineren. De communicatie verloopt via de uitwisseling van berichten. Bij het uitwisselen van berichten wordt niets gedeeld door processen dus wederzijdse uitsluiting is geen controle eis voor dit soort samenwerking. De problemen deadlock en uithongering doen zich wel voor. Vereisten voor wederzijdse uitsluiting 1. Wederzijde uitsluiting moet dwingend opgelegd worden: slechts 1 proces van alle processen met kritieke secties voor dezelfde bron of hetzelfde gedeelde object wordt tegelijkertijd in de kritieke sectie toegelaten. 2. Een proces dat stopt in zijn niet kritieke sectie moet dat doen zonder andere processen te verstoren 3. Deadlocks en starvation mogen niet voorkomen 4. Een proces dat toegang wil tot een kritieke sectie moet zonder vertraging toegang krijgen, wanneer er geen enkel ander proces zich in zijn kritieke sectie bevindt 5. Geen veronderstellingen gebruikt over de relatieve snelheiden van processen/ aantal processen 6. Een proces mag zich maar een beperkte tijd in zijn kritieke sectie bevinden Wederzijdse uitsluiting: hardwareondersteuning Uitschakelen van interrupts systeem met 1 processor: concurrerende processen kunnen elkaar niet overlappen een proces wordt afgebroken door een interrupt => ervoor zorgen dat een proces niet kan onderbroken worden door interrupts uit te schakelen (achterliggende theorie: wanneer een interrupt optreedt gaat de processor in kernelmode en voert daar de gewenste code uit, dus, andere code wordt uitgevoerd tussen de kritieke sectie, in het slechtste geval verandert die code iets waarmee het proces in usermode mee bezig was waardoor alles in het water valt. Een ander probleem kan zijn dat de interrupt vereist dat een ander proces wordt toebedeeld aan de processor waardoor het eerste proces geblokkeerd wordt temidden van zijn kritieke sectie. Het kan dan even duren vooraleer dat proces weer vrijkomt (denk maar aan FIFO) waardoor de bron die het proces gebruikt lange tijd geblokkeerd blijft.

29 while(true) { schakel interrupts uit; voer kritieke sectie uit; schakel interrupts in; rest; } => omdat de kritieke sectie niet kan worden onderbroken is mutual exclusion gegarandeerd! Nadelen: efficiëntie uitvoering daalt want processor wordt beperkt in zijn mogelijkheid om processen te verweven werkt niet in multiprocessoromgeving (!!daar heeft het geen zin om de interrupts op 1 processor even af te zetten met de reden dat de code daarom atomair kan verlopen want op de andere processoren kunnen er processen lopen die tegelijkertijd dingen gaan veranderen aan variabelen die het eerste proces in zijn kritieke sectie gebruikt. een oplossing zou dan zijn om op de gebruikte processor interrupts te disablen en op de andere processen de processen te blokkeren maar dat is zo inefficiënt dat dat geen goed idee is) Speciale machine instructies de testset en de exchange instructie Beiden zijn machineïnstructies die ervoor zorgen dat de kritieke sectie op atomair niveau wordt uitgevoerd! Parbegin betekent dat het programma deze processen parallel moet uitvoeren Instructie test and set testandset gaat controleren of een integer == 0, zo ja, dan wordt die op 1 gezet en wordt er true gereturnd => uit de while lus en de kritieke sectie wordt uitgevoerd, als er dan ondertussen een ander proces ook zijn kritieke sectie wil uitvoeren, dan wordt er false gereturnd en zit dat proces vast in de lus tot wanneer het vorige proces bolt terug op 0 zet. De processen die zo in de loop terechtkomen zijn zijn dan niet geblokkeerd maar busy waiting (processor wordt maw gebruikt maar is niet nuttig aan het doen, proces zit immers in een loop); busy waiting wil zeggen: een proces kan niets doen tot het toestemming krijgt de kritieke sectie te betreden. Welk het volgende proces wordt dat wordt uitgevoerd wanneer bolt terug 0 is, is het eerste proces dat test of bolt == 0. Dus eigenlijk is dit vrij random (afhankelijk van de schedulingsstrategie) Instructie exchange Wisselt de inhoud van een register met die van een geheugenlocatie. In het voorbeeld is het iets simpeler, daar worden een 0 en een 1 gewisseld. Enkel het proces waarvoor geldt dat keyi == 0 (en dus bolt == 0 bij het begin van de uitvoering) mag de kritieke sectie betreden, al de rest moet wachten tot het eerste proces bolt terug op 0 heeft gezet. Eigenschappen van de benadering met machine-instructies Voordelen van het werken met machine-instructies: 1. toepasbaar op alle processen op een machine met 1 processor en op alle processen op een systeem van multiprocessing die het hoofdgeheugen delen <-> als ze geen geheugen delen, dan delen ze ook geen variabelen en kan er dan ook niet met de waarde van variabelen gewerkt worden!! 2. eenvoudig => makkelijk te controleren

30 3. kan worden gebruikt voor het ondersteunen van meerdere kritieke secties waarbij elke kritieke sectie zijn eigen variabele kan hebben Nadelen van het werken met machine-instructies: 1. busy-waiting: proces blijft processortijd verbruiken terwijl het niets nuttig aan get doen is 2. starvation kan nog steeds: aangezien het willekeurig is welk proces een proces opvolgt dat uit zijn kritieke sectie komt en als er meerdere processen zijn die 'busy waiting' zijn, dan kan het zijn dat een proces zeer lang in de wachtrij staat 3. deadlock: P1 gaat in kritieke sectie maar wordt onderbroken door P2 dat een hogere prioriteit heeft, echter, om te voltooien heeft P2 dezelfde bron nodig als P1 maar die is geblokkeerd door P2 en P1 wacht op de voltooiing van P2... (dan maakt het niet uit of er even een ander proces wordt geactiveerd want de clue is dat deze twee processen niet verder kunnen, tenzij het OS P2 plots een lagere prioriteit geeft dan P1 waardoor P1 weer actief kan worden...) Semaforen Grondbeginsel : Twee of meer processen kunnen samenwerken dmv signalen waarbij een proces gedwongen wordt te stoppen op een opgegeven plaats totdat het een signaal ontvangt dat het mag verdergaan. Voor het verzenden van een signaal via semafoor s voert een proces de primitieve semsignal(s) uit. Voor het ontvangen van een signaal de primitieve semwait(s). Principe: semwait(s) => een proces wordt onderbroken totdat semsignal(s) door een ander proces verzonden is. Om het gewenste effect te bereiken kunnen we de semafoor beschouwen als een variabele die een gehele waarde heeft en waarvoor drie bewerkingen zijn gedefinieerd : 1. semafoor wordt geïnitialiseerd op een niet-negatieve waarde 2. semwait(s) verlaagt de waarde van s met 1, wordt de waarde negatief, dan wordt dat proces geblokkeerd 3. semsignal(s) verhoogt de waarde van s, was de waarde niet positief en nu wel, dan wordt een proces dat geblokkeerd was door semwait(s) nu gedeblokkeerd. semwait() en semsignal() zijn primitieven en worden atomair uitgevoerd ( zonder onderbreking ). Een binaire semafoor kan worden geïnitialiseerd op waarde 0 of 1 en kan ook alleen maar deze twee waarden hebben. 1. Bewerking semwaitb() controleert waarde van de semafoor. Als de waarde nul is wordt het proces dat semwaitb() uitvoert geblokkeerd. Als de waarde 1 is wordt het proces verder uitgevoerd en de waarde in 0 veranderd. 2. De bewerking semsignalb() controleeert of er processen op deze semafoor geblokkeerd zijn. Als dat het geval is, wordt een proces dat geblokkeerd is door een bewerking semwaitb vrijgegeven. Zijn er geen geblokkeerde processen, waarde => 1 Niet binaire semaforen worden vaak een tellende of algemene semafoor genoemd. Het proces dat het langst is geblokkeerd wordt als eerste vrijgelaten uit de wachtrij. Bij deze strategie is een semafoor STERK. Als de volgorde van processen uit de wachtrij niet is vastgelegd wordt het een ZWAKKE semafoor. STERKE semaforen garanderen de afwezigheid van uithongering, zwakke niet.

31 !!!Voordeel t.o.v. machine-instructies: de processen worden hier geblokkeerd => de processor voert ze niet meer uit en verdoet er dan ook zijn tijd niet mee <-> busy waiting bij machine-instructies!!! Wederzijdse uitsluiting Op elk moment kan de waarde van de semafoor daarbij als volgt worden geïnterpreteerd: De waarde van de semafoor ( bij >= 0 ) is het aantal processen dat semwait(s) zonder onderbreking kan uitvoeren De waarde van de semafoor ( bij < 0 ) is het aantal processen dat is onderbroken in de wachtrij van de semafoor. Implementatie van semaforen Zoals eerder gezegd is het essentieel dat de bewerkingen semwait en semsignal worden geïmplementeerd als atomaire primitieven. Mogelijkheden : in hard-of firmware software: probleem: als je bvb naar het algoritme van Dekker kijkt, dan is er veel overhead omdat de processor een proces aan het uitvoeren kan zijn dat in wezen niets doet, buiten dan controleren of de vlaggen wel goed staan mutual exclusion door mechanisme in de hardware: testandset en interrupts Bij testandset wordt de de testset gebruikt bij de wait en de signal. Er kan maar 1 proces per keer een semwait(s) doen => wanneer een eerste proces dit wil uitvoeren, dan wordt s.flag op 1 gezet waardoor, als er een tweede proces is dat ook een semwait(s) wil oproepen, even moet wachten vooraleer het de semafoor kan aanpassen => in de while loop (= busy waiting). Wanneer dan het eerste proces de wait heeft uitgevoerd, dan wordt s.flag weer op 0 gezet zodat een proces dat hierop aan het wachten was, uit de loop kan en de semafoor kan aanpassen. Dit staat los van het feit of het proces al dan niet geblokkeerd gaat geraken wanneer de waarde van de semafoor < 0, het zorgt er gewoon voor dat er geen 2 processen tegelijkertijd de semafoor kunnen aanpassen Nadeel is dat er dan gedaan wordt aan busy waiting maar omdat een semwait niet zo lang duurt is dat nog redelijk. Idem voor bij het enabelen en disabelen van interrupts (alleen bij systemen met 1 processor!!!!!). Dit wordt gedaan zodat een semwait en semsignal atomaire acties kunnen zijn (ze kunnen dan niet worden onderbroken door een interrupt) het kleine nadeel is dan wel dat de processor dan even geen processen kan verweven maar omdat semwait en semsignal zo kort duren valt dit nadeel vrij goed mee. Monitoren Semaforen hebben nadelen : verantwoordelijkheid voor plaatsing van semwait en semsignal ligt volledig bij de programmeur wat dus de kans op fouten groter maakt dan bij monitors waar deze verantwoordelijkheid gedeeltelijk wordt afgeschoven op het vertaalprogramma. semwait en semsignal kunnen overal verspreid staan over een programma en het is soms moeilijk om te zien wat hun invloed juist is <-> een monitor is meer afgelijnd, het is het creëren van een atomair blok daar waar er eerst geen was Monitor is een constructie in een programmeertaal die een functionaliteit biedt die vergelijkbaar is met die van semaforen, maar die gemakkelijker te besturen is. Ook is ze geïmplementeerd als een programmabibliotheek. Dit biedt de mogelijkheid grendels op elk object te plaatsen.

32 Monitor met signal Een monitor is een softwaremodule die bestaat uit een reeks procedures, een initialisatiereeks en een lokale gegevens. Kenmerken : 1. Lokale gegevensvariabelen zijn uitsluitend toegankelijk voor de procedures van de monitor en niet voor andere externe procedures. 2. Een proces benadert de monitor door een van de procedures ervan aan te roepen. 3. Slecht één proces tegelijk kan worden uitgevoerd in de monitor. Door slechts 1 proces tegelijk toe te laten kan de monitor worden gebruikt als een voorziening voor wederzijdse uitsluiting. Een monitor ondersteunt ook synchronisatie door gebruik te maken van conditievariabelen die zijn opgenomen binnen de monitor en die alleen binnen de monitor toegankelijk zijn. 2 functies werken hiermee : 1. cwait(c) : stelt de uitvoering van het aanroepende proces uit op conditie c. De monitor is daarna beschikbaar voor gebruik door een ander proces. 2. csignal(c) : hervat de uitvoering van een bepaald proces dat werd onderbroken na een cwait op dezelfde conditie. Zijn er meerdere van dergelijke processen, kies dan één proces; zijn er geen wachtende, doe dan niets! wanneer er bij monitors een signal wordt verstuurd maar er is helemaal geen proces dat wacht op de conditievariabele (er zit geen proces in de wachtrij van de variabele), dan gebeurt er helemaal niets <> semaforen Dus: monitor toegankelijk voor slechts 1 proces per keer, als eerste proces binnenkomt, dan wordt de conditie gewijzigd waardoor een tweede proces door cwait(c) uit te voeren terechtkomt in een wachtrij van de conditie totdat eerste proces een signal uitvoert dat de monitor vrij is => 1 proces uit de wachtrij hervat zijn uitvoering net na de cwait(x). De verantwoordelijkheid voor de correctheid van de synchronisatie ligt nog steeds bij de programmeur, maar : Voordelen tov semaforen: de synchronisatiefuncties blijven beperkt tot de monitor => overzichtelijker en makkelijker te controleren <-> semaforen: kunnen over het hele programma staan. Nadelen van monitors: een goede synchronisatie vereist dat procedures worden aangeroepen voor en na het gebruik van de gedeelde bron. Gebeurt dit niet of verkeerd, dan bestaat de kans dat een thread of een proces toch nog toegang heeft tot een gedeelde bron terwijl een ander proces daar ook mee bezig is geneste monitoren kunnen deadlocks veroorzaken: P1 zit in een procedure van een high-level monitor en gaat over naar een procedure van een lower-level monitor, daar wordt het proces in een wachtrij geplaatst. Alles goed en wel voor de lower-level monitor, die komt zo vrij voor een ander proces maar de high-level monitor is nog steeds bezet => geen ander proces kan die gebruiken => deadlock

33 Gelijktijdigheid : Deadlocks en uithongering Deadlock en starvation zijn twee problemen ten gevolge van de oplossingen om gelijktijdige verwerking te ondersteunen Beginselen van deadlock Deadlock: een permanente blokkering van processen die met elkaar wedijveren om bronnen of die met elkaar communiceren fig 6-2 p 285!! Herbruikbare hulpbronnen Reusable resource <-> consumable resource bvb.: hoofdgeheugen, secundair geheugen, processor, databases en semaforen Een herbruikbare (hulp)bron is een bron die veilig door 1 proces tegelijkertijd kan worden gebruikt en na dit gebruik is de bron er nog steeds, ze geraakt door gebruik niet op Deadlock: wanneer twee processen een bron vasthouden en verzoeken om een andere bron zie voorbeeld p288 voorbeeld van deadlock bij geheugen: wanneer er gevraagd wordt om geheugen dat nog moet vrijgezet worden door een ander proces dat echter zelf nog om geheugen vraagt en niets kan vrijzetten omdat het wacht op geheugen Verbruikbare hulpbronnen Consumable resource: een bron die kan worden gemaakt en vernietigd; het aantal verbruikbare bronnen van een bepaald soort is meestal onbeperkt bvb.: interrupts, signalen, berichten(!!! processen die met elkaar communiceren!!) Deadlock: P1 wacht op een bericht van P2 om naar P2 te versturen terwijl P2 wacht op een bericht van P1 om naar P1 te versturen => een deadlock treedt op als het ontvangen blokkerend is brontoewijzingsschema's

34 Een punt is een voorstelling van een bron, hierboven is er van elke bron maar 1 instantie een proces vraagt om een bron maar die nog niet toegewezen, pas wanneer er een pijl van een bron naar een proces gaat is de bron toegewezen aan dat proces. Voorbeeld van een deadlocksituatie: Wanneer er meerdere instanties van een herbruikbare bron kunnen toegewezen worden (bvb van I/O apparaten) aan een proces is de kans op een deadlock kleiner Condities voor deadlock Er zijn drie voorwaarden die er voor zorgen dat een situatie in een deadlock kan verzeild geraken: 1. wederzijdse uitsluiting: een bron mag maar aan 1 proces gelijktijdig worden toegewezen 2. vasthouden en wachten: een proces mag een bron vasthouden terwijl het wacht op de toewijzing van andere bronnen 3. geen preëmptieve onderbreking: een bron kan niet zomaar worden afgenomen van een proces dat de bron vasthoudt Deze drie voorwaarden zijn echter wenselijk!! mutual exclusion: consistentie van gegevens en gelijktijdigheid geen preëmptieve onderbreking: tenzij met een zeer goed rollback-mechanisme (stel: een proces is bezig met bewerkingen op gegevens uit een bestand, opeens wordt dat bestand afgenomen van dat proces en dat bestand gaat lezen uit dat bestand => een fout) Noodzaak aan een 4e voorwaarde voor deadlock: 4. Cirkelvormig wachten: een ketting van wachtende processen waarbij de processen wachten op het vrijkomen van een bron dat een ander proces vasthoudt De eerste drie condities kunnen leiden tot de vierde. Wanneer de vierde voorwaarde waar is, dan is er een deadlock. Er zijn drie strategiën om om te gaan met een deadlock: voorkomen, vermijden en detecteren

35 Samenvatting: aanpak Toewijzing bronnen Verschillende vormen Voordelen Nadelen Voorkomen bronnen worden met mondjesmaat toegewezen alle bronnen tegelijk aanvragen + preëmptieve ingreep is niet nodig + werkt goed bij processen die activiteiten in één klap uitvoeren - inefficiënt - vertraagt het starten van processen - toekomstige behoefte aan bronnen moet gekend zijn preëmptieve ingreep + goed voor gebruik bij processen waarbij de toestand gemakkelijk kan worden opgeslaan en hersteld - preëmptieve onderbrekingen treden vaker op dan nodig ordenen van bronnen + implementatie dmv controles tijdens compilatie - maakt toenemende vragen om bronnen onmogelijk Vermijden middenweg tussen detecteren en voorkomen bijsturen om minstens 1 veilige weg te vinden + preëmptieve onderbreking - toekomstige is niet noodzakelijk behoeften aan bronnen moeten bekend zijn - processen kunnen lange tijd geblokkeerd zijn Detecteren aangevraagde bronnen indien mogelijk altijd vrijgeven periodiek aanroepen om te testen op deadlock + vertraagt nooit het starten van een proces + maakt online afhandeling mogelijk - verlies door preëmptieve onderbreking Voorkomen van deadlock deadlock wordt uitgesloten twee mogelijkheden: 1. indirecte methode: voorkomen van 1 van de 3 noodzakelijke voorwaarden 2. directe methode: voorkomen van het cirkelvormig wachten Wederzijdse uitsluiting kan niet onmogelijk worden gemaakt: sommige bronnen (bvb naar een bestand schrijven) vereisen nu eenmaal wederzijdse uitsluiting en dan vereist dit ook ondersteuning door OS! Vasthouden en wachten het proces vraagt in één keer alle vereiste bronnen aan en wordt geblokkeerd zolang er een of meerdere bronnen niet beschikbaar zijn inefficiënt: op die manier kan een proces lang geblokkeerd blijven terwijl het mss al gedeeltelijk kan

36 uitgevoerd worden met slechts een deel van de bronnen reeds toegewezen bronnen aan een dergelijk geblokkeerd proces zijn ontoegankelijk voor andere processen terwijl deze bronnen niet worden gebruikt Dit vereist ook dat een proces vanaf het begin weet welke bronnen het zal nodig hebben en dat het weet waar het deze kan vinden Geen preëmptieve onderbreking er zijn verschillende manieren om tóch preëmptief te onderbreken: een proces bezet een aantal bronnen, verzoekt om een andere -> verzoek wordt geweigerd => proces moet alle bronnen vrijgeven en er een volgende keer terug om verzoeken OS onderbreekt preëmptief een proces dat om een bron vraagt dat bezet is door een ander proces en eisen dat dit zijn bronnen vrijgeeft(voorkomt enkel een deadlock wanneer beide processen een andere prioriteit hebben => preëmptief onderbreken proces met laagste prioriteit) Onderbreken heeft alleen zin bij bronnen waarvan de toestand gemakkelijk kan worden opgeslagen en hersteld, zoals bij de processor Cirkelvormig wachten Dit is de directe manier door het definiëren van een lineaire rangorde van soorten voorzieningen: aan een proces zijn bronnen toegewezen van het soort R, dan mag dit proces enkel nog maar verzoeken om bronnen met een hogere rangorde dan R volgende situatie kan dan niet meer: P1 heeft bron Ri bezet en vraagt om bron Rj P2 heeft bron Rj bezet en verzoekt om Ri Dit kan niet want als i < j dan kan j!< i dus deze deadlock is opgelost want P2 mag Ri niet aanvragen Inefficiënt want het vertraagt de processen en weigert onnodig de toegang tot bronnen (omdat dit in een bepaalde volgorde moet gebeuren, zelfs al zijn de bronnen vrij) Vermijden van deadlock voorkomen deadlock: beperkingen opleggen aan bronaanvragen om zo minstens 1 van de vier voorwaarden te omzeilen => inefficiënt gebruik van systeembronnen en inefficiënte uitvoering van processen vermijden van deadlock: de eerste drie voorwaarden zijn toegestaan maar er worden keuzes gemaakt om er voor te zorgen dat het nooit tot een deadlock komt => er is meer ruimte voor gelijktijdigheid maar, dit vereist wel dat op voorhand geweten is om welke bronnen zal gevraagd worden 2 benaderingen om deadlock te vermijden: 1. een proces waarvan de bronaanvragen tot een dead lock kunnen leiden niet starten 2. wanneer een bronaanvraag van een proces kan leiden tot een deadlock, dan wordt deze aanvraag niet verwerkt

37 Weigeren van een nieuw proces Zeer inefficiënt: Gaat ervan uit dat alle processen tegelijkertijd hun maximale claim kunnen maken => een nieuw proces wordt alleen gestart als het systeem alle bronnen die de reeds bestaande processen kunnen opvragen aan die processen kunnen worden toegewezen en als de bronnen die het nieuw proces kan aanvragen ook kunnen worden toegewezen Probleem: het is niet omdat twee processen een bron tegelijkertijd kunnen opvragen dat dat daarom ook zo is Weigeren om bronnen toe te wijzen Dit werkt volgens het bankiersalgoritme van Dijkstra. Er worden 2 soorten toestanden onderscheiden: veilige toestand: er is op zijn minst 1 manier waarop de processen bronnen toegewezen kunnen krijgen die niet leidt tot een deadlock onveilige toestand: een mogelijke deadlocksituatie (die wordt vermeden door het systeem door de bronaanvraag niet te behandelen en het proces dat de aanvraag doet te blokkeren) zie fig 6-7 op die figuur is een voorbeeld te zien van een veilige toestand, immers, er is op zijn minst 1 manier waarop de verschillende processen kunnen uitgevoerd worden die niet leidt tot een deadlock fig 6-8 p301: onveilige situatie P1 verzoekt om 1 allocatie van bron 1 en 1 van bron 3 => er zijn geen instanties meer van bron 1 terwijl er daar minstens 1 van nodig is opdat er een proces is dat volledig kan uitgevoerd worden => het toewijzen van de bronnen aan proces 1 leidt tot een deadlock en dit wordt voorkomen door deze aanvraag te negeren en P1 te blokkeren waardoor een ander proces actief wordt (hopelijk P2) dat een aanvraag doet die NIET leidt tot een deadlock