Threads

Start Omhoog Computersystemen Besturingssystemen Processen Threads Gelijktijdigheid: Wederzijdse uitsluiting Gelijktijdigheid: deadlock en utisterving Geheugenbeheer Virtueel geheugen Uniprocessor planning Multiprocessor en real-time planning Bestandsbeheer I/O beheer en schijfplanning Bash Powershell Begrippen

Dit hoofdstuk behandeld wat meer geavanceerde concepten met betrekking tot procesbeheer, welke worden gevonden in een aantal hedendaagse besturingssystemen. We laten zien dat het concept van een proces gecompliceerder en subtiel is dan tot nu toe werd aangenomen. In feite werd een proces voorgesteld als uit twee aparte en mogelijk onafhankelijke delen bestond: de een in betrekking tot broneigenaarschap en de ander met betrekking tot uitvoering. Dit onderscheid heeft in veel besturingssystemen tot de ontwikkeling van threads.

4.1. Processen en threads

Tot nu toe is alleen het concept van een proces besproken als twee karakteristieken:

  • Broneigenaarschap: Een proces bevat een virtuele adresruimte om het procesbeeld te bevatten; herinner van hoofdstuk 3 dat het procesbeeld de collectie is van programma's, data, stack en attributen bepaald in het procescontroleblok. Van tijd tot tijd kan een proces controle of eigenaarschap van bronnen, zoals hoofdgeheugen, I/O kanalen, I/O apparaten en bestanden toewijzen. Het besturingssysteem vervult een beveiligingsfunctie om ongewenste interferentie tussen processen te voorkomen met respect naar de bronnen.
  • Planning/uitvoering: De uitvoering van een proces volgt een uitvoeringspad (trace) door één of meerdere programma's (bv. Figuur 1.5). Deze uitvoering kan tussengevoegd zijn met dat van andere processen. Dus een proces heeft een uitvoeringstoestand (Running, Ready, etc.), een afhandelingsprioriteit en is de entiteit dat gepland en gedispatched wordt door het besturingssysteem.
  • Enkel gedachten moeten de lezer overtuigen dat deze twee karakteristieken onafhankelijk zijn en als zodanig door het besturingssysteem kan worden behandeld. Dit wordt gedaan in een aantal besturingssystemen, specifiek recent ontwikkelde systemen. Om de twee karakteristieken te onderscheiden wordt naar de dispatchingseenheid gebruikelijk verwezen als een thread of lichtgewicht proces, terwijl naar de eenheid van broneigenaarschap meestal verwezen wordt als een proces of taak.

    4.1.1. Multithreading

    Multithreading verwijst naar de mogelijkheid van een besturingssysteem om meerdere, evenwijdige uitvoeringspaden binnen een enkel proces te ondersteunen. De traditionele aanpak van een enkele uitvoeringsthread per proces, waarin met het concept van een thread niet kan herkenning, wordt naar verwezen als een single-threaded aanpak. De twee opstellingen aan de linkerkant van figuur 4.1 zijn single-threaded benaderingen. MS-DOS is een voorbeeld van een besturingssysteem dat een enkel gebruikersproces en een single thread ondersteund. Andere besturingssystemen zoals enkele varianten van UNIX ondersteunen meerdere gebruikersprocessen maar enkel één thread per proces. Het rechtergedeelte van figuur 4.1 beschrijft de multithreaded aanpakken. Een Java run-time omgeving is een voorbeeld van een systeem met één proces met meerdere threads. Van belang is het gebruik van meerdere processen waarvan elk meerdere threads ondersteund. Deze aanpak wordt gebruikt in Windows, Solaris en vele andere moderne versies van UNIX.

    In een multithreaded omgeving wordt een proces gedefinieerd als een eenheid van brontoewijzing en een eenheid van beveiliging. Het volgende word geassocieerd met processen:

  • Een virtuele adresruimte dat het procesbeeld bevat
  • Beveiligde toegang tot processoren, andere processen (voor interproces communicatie), bestanden en I/O bronnen (apparaten en kanalen)
  • Binnen een proces kunnen er één of meerdere threads zijn, elk met het volgende:

  • Een thread uitvoeringstoestand (Running, Ready, etc)
  • Een opgeslagen context als het niet in uitvoering is; een manier om een thread te zien is als een onafhankelijke programmateller besturing binnen een proces
  • Een uitvoeringsstack
  • Enkele per-thread statische opslag voor variabelen
  • Toegang tot het geheugen en bronnen van zijn proces, gedeeld door alle threads van dat proces
  • Figuur 4.2 illustreert het onderscheid tussen threads en processen vanuit het procesbeheer oogpunt. In een single-threaded proces model bevat de voorstelling van een proces zijn procescontroleblok en gebruikersadresruimte, alsook gebruikers en kernel stacks om het oproep/terugkeer gedrag van het proces in uitvoering te beheren. Terwijl het proces in uitvoering is bestuurt het de processor registers. De inhoud van deze registers worden bewaard als het proces niet in uitvoering is. In een multithreaded omgeving is er nog steeds een enkele procescontroleblok en gebruikersadresruimte geassocieerd met het proces, maar nu zijn er ook aparte stacks voor iedere thread, alsook een apart controleblok voor iedere thread dat registerwaarden, prioriteiten en andere thread-gerelateerde toestand informatie bevat.

    Dus alle threads van een proces delen de toestand en bronnen van dat proces. Ze bevinden zich in dezelfde adresruimte en hebben toegang tot dezelfde data. Als één thread item van data in het geheugen veranderd, zien andere threads de resultaten als of wanneer zij dat item benaderen. Als één thread een bestand opent met lees privileges kunnen de andere threads in hetzelfde proces ook lezen van dat bestand.

    De hoofdzakelijke voordelen van threads komen van de prestatie implicaties:

    1. Het neemt veel minder tijd in beslag om een nieuwe thread in een bestaand proces te creëren dan een nieuw proces te creëren.
    2. Het neemt minder tijd in beslag om thread te beëindigen dan een proces.
    3. Het neemt minder tijd in beslag om tussen twee threads binnen hetzelfde proces te wisselen dan om te wisselen tussen processen.
    4. Threads breiden de efficiëntie in communicatie uit tussen verschillende programma's in uitvoering. In de meeste besturingssystemen vereist de communicatie tussen onafhankelijke processen de interventie van de kernel om te voorzien in beveiliging en mechanismen die nodig zijn voor communicatie. Echter, omdat threads binnen hetzelfde proces geheugen en bestanden deelt kunnen ze met elkaar communiceren zonder tussenkomst van de kernel.

    Een thread constructie is ook handig op een enkele processor om de structuur van een programma te vereenvoudigen dat logischerwijs diverse verschillende zaken uitvoert.

    We geven hier vier voorbeelden van het gebruik van threads in een enkele gebruiker multiprocessing systeem:

  • Voorgrond- en achtergrondwerk: Bijvoorbeeld in een spreadsheet programma, kan één thread de menu's tonen en de gebruikersinput lezen, terwijl een andere thread gebruikerscommando's en updates voor de spreadsheet uitvoert. Deze manier van aanpak verhoogt vaak de waargenomen snelheid van applicatie door het programma toe te laten de volgende commando op te roepen voordat de vorige uitgevoerd is.
  • Asynchrone verwerking: Asynchrone elementen in het programma kunnen geïmplementeerd worden als threads. Bijvoorbeeld als beveiliging tegen stroomuitval kan een tekstverwerker zo ontworpen zijn om zijn RAM (random access memory) buffer iedere minuut naar disk te schrijven. Een thread kan geschreven worden die als enige taak heeft om periodiek een back-up te maken en dat het zichzelf rechtstreeks inplant met het besturingssysteem; er is geen noodzaak voor ingewikkelde code in het hoofdprogramma die voorziet in tijd controles of om de in- en uitvoer te coördineren.
  • Snelheid van uitvoering: Een multithreaded proces kan een batch van data verwerken terwijl het de volgende batch reeds leest van een apparaat. Op een multiprocessor systeem, kunnen meerdere threads van hetzelfde proces de mogelijkheid hebben om gelijktijdig uitgevoerd te worden. Dus zelfs ondanks dat een thread geblokkeerd staat omdat het aan het wachten is op een I/O operatie kan een andere thread uitvoerende zijn.
  • Modulaire programmastructuur: Programma's die gepaard gaan met verscheidenheid aan activiteiten of een verscheidenheid van bronnen en bestemmingen van in- en uitvoer kunnen makkelijker ontworpen worden door het gebruik van threads.
  • In een besturingssyteem dat threads ondersteund, wordt planning en dispatching gedaan op basis van een thread; derhalve wordt de meeste van de toestand informatie aangaande tot de uitvoering behandeld in thread-level structuren. Er zijn echter ook verschillende acties dat al de threads in een proces beïnvloeden en dat het besturingssysteem het op proces niveau moet beheren. Bijvoorbeeld opschorting gaat gapaard met het verwisselen van de adresruimte van één proces uit het hoofdgeheugen om plaats te maken voor de adresruimte van een ander proces. Omdat alle threads in een proces dezelfde adresruimte delen, worden alle threads op hetzelfde moment opgeschort. Gelijkaardig, beëindiging van een proces beëindigt alle threads binnen dat proces.

    4.1.2. Thread functionaliteit

    4.1.2.1. Thread toestanden

    Zoals met processen zijn de kerntoestanden voor een thread Running, Ready en Blocked. In het algemeen heeft geen nut om opgeschorte toestanden met threads te associëren, omdat zulke toestanden proces-niveau concepten zijn. In het algemeen als een proces is verwisseld-uit (swapped-out), worden al zijn noodzakelijke threads ook verwisseld uit (swapped out) omdat ze allemaal dezelfde adresruimte delen.

    Er zijn vier basis thread operaties geassocieerd bij een verandering in de thread toestand:

  • Spawn: Typisch wanneer een nieuw proces opgeschort wordt, wordt een thread voor dat proces ook opgestart. Vervolgens kan een thread binnen dat proces een andere thread binnen datzelfde proces ook opstarten, dat de nieuwe thread van een instructie pointer en argumenten voorziet. De nieuwe thread is voorzien van zijn eigen register context en stack ruimte en wordt geplaatst in de Ready wachtrij.
  • Block: Als een thread op een gebeurtenis moet wachten zal het geblokkeerd worden (de gebruikersregisters, programmateller en stackpointers worden bewaard). De processor kan nu een andere klaarstaande thread in hetzelfde of ander proces invoegen om uitgevoerd te worden.
  • Unblock: Als een gebeurtenis waarvoor een thread is geblokkeerd optreedt, zal de thread verplaatst worden naar de Ready wachtrij.
  • Finish: Als een thread voltooid word de toewijzing van de register context en stacks weggehaald.
  •  

    4.1.2.2. Threadsynchronisatie

    Alle threads van een proces delen dezelfde adresruimte en andere bronnen, zoals open bestanden. Enige wijziging van een bron door één thread heeft invloed op de omgeving van de andere threads in datzelfde proces. Het is daarvoor noodzakelijk om de activiteiten van de verschillende threads te synchroniseren zodat ze niet met elkaar interfereren of data structuren corrumperen. Bijvoorbeeld als ieder van de twee threads op hetzelfde moment een element aan een dubbele geschakelde lijst probeert toe te voegen kan één van de elementen verloren raken en kan de lijst misvormd raken.

    De opgeworpen kwesties en de gebruikte technieken in synchronisatie van threads zijn in het algemeen dezelfde als die voor synchronisatie van processen. Deze kwesties en technieken zijn onderwerp in hoofdstuk 5 en 6.

    4.2. Types van threads

    4.2.1. Gebruikers- en kernelniveau threads

    Er zijn twee ruime categorieën van implementaties van threads: gebruikersniveau threads (ULT's) en kernelniveau threads (KLT's). Naar deze laatste wordt in de literatuur ook wel verwezen als kernel ondersteunde treads of lightgewicht processen.

    4.2.1.1. Gebruikersniveau

    In een zuivere ULT faciliteit wordt al het werk van threadbeheer gedaan door de applicatie en de kernel heeft geen weet van het bestaan van threads. Elke applicatie kan zo geprogrammeerd worden om multithreaded te zijn door gebruik te maken van een thread bibliotheek, welk een pakket van routines is voor het ULT beheer. De thread bibliotheek bevat code voor planning om threads aan te maken, te vernietigen, om berichten en data tussen de threads door te geven, voor planning van threaduitvoering en om thread context te bewaren en te herstellen.

    Er zijn een aantal voordelen voor het gebruik van ULT's in plaats van KLT's, inclusief het volgende:

    1. Threadwisseling vereist geen kernel mode privileges, omdat alle thread management datastructuren binnen de gebruikersadresruimte van een enkel proces zitten. Daardoor zal het proces voor het threadbeheer niet schakelen naar de kernel mode. Dit scheelt in de overhead van twee modewisselingen (gebruikers naar kernel; kernel terug naar gebruiker).
    2. Planning kan applicatie specifiek zijn. Een applicatie kan voordeel halen uit een eenvoudige round-robin planningsalgoritme, terwijl een ander voordeel haalt uit een prioriteiten gebaseerd planningsalgoritme. Het planningsalgoritme kan voor de applicatie op maat gemaakt worden zonder hiervoor het onderliggende besturingssysteem planningsmechanisme te verstoren.
    3. ULT's kunnen op ieder besturingssysteem draaien. Er zijn geen veranderingen in de onderliggende kernel nodig om ULT's te ondersteunen. De thread bibliotheek is een set van functies op applicatieniveau die gedeeld worden door alle applicaties.

    Er zijn twee duidelijke nadelen van ULT's ten opzichte van KLT's:

    1. In een gebruikelijk besturingssysteem zijn veel systeemoproepen geblokkeerd. Als resultaat, wanneer een ULT een systeemoproep uitvoert, blokkeert niet enkel die thread, maar ook alle threads binnen dat proces blokkeren.
    2. In een pure ULT strategie van een multithreaded applicatie geen voordeel halen uit multiprocessing. Op elk moment wijst een kernel een proces maar toe aan één processor. Daardoor kan alleen een enkele thread binnen een proces per keer uitgevoerd worden. Effectief hebben we meervoudige applicatieniveau programma's binnen een enkel proces. Terwijl deze multiprogrammering kan resulteren in een significante snelheidsverbetering van de applicatie, zijn er ook applicaties dat voordeel zijn halen als ze simultaan uitgevoerd zouden worden.

    Er zijn mogelijkheden om deze twee problemen te omzeilen. Bijvoorbeeld beide problemen kunnen worden vermeden door de applicatie te schrijven als meerdere processen in plaats van meerdere threads. Maar deze methode schakelt het hoofdzakelijke voordeel van threads uit: Iedere wissel wordt een proces wissel in plaats van een thread wissel wat resulteert in een veel grotere overhead.

    Een andere manier om dit te vermijden is het gebruik van een techniek dat Jacketing is genoemd. Het doel van jacketing is om een geblokkeerde systeemoproep te converteren naar een niet geblokkeerde systeemoproep. Binnen deze jacket is er code dat controleert of het I/O apparaat nog bezig is. Als dat zo is, zal de thread in Blocked toestand worden gezet en wordt de controle overgedragen (via de threads bibliotheek) naar een andere thread. Als deze thread nadien de controle teruggeeft zal de jacket routine het I/O apparaat opnieuw controleren.

    4.2.1.2. Kernelniveau

    In een zuivere KLT faciliteit word al het werk gedaan door de kernel. Er is geen threadbeheercode in het applicatieniveau, er is eenvoudigweg een application programming interface (API) naar de kernel faciliteit. Windows is een voorbeeld die deze methode gebruikt.

    Figuur 4.5b beschrijft de zuivere KLT methode. De kernel onderhoud de context informatie van dat proces als een geheel als voor de individuele threads binnen het proces. Planning door de kernel wordt op thread basis gedaan. Deze aanpak ondervangt de twee hoofdzakelijke bezwaren van de ULT methode. Ten eerste kan de kernel simultaan meerdere threads van hetzelfde proces over meerdere processoren plannen. Ten tweede als één thread in een proces geblokkeerd is kan de kernel een andere thread van hetzelfde proces inplannen. Een ander voordeel van de KLT methode is dat de kernel routines zelf multithreaded kunnen zijn.

    Het voornaamste nadeel van de KLT methode vergeleken met de ULT methode is dat de besturingsoverdracht tussen threads binnen hetzelfde proces een modus switch naar de kernel vereist.

    Terwijl er een significante snelheidsverbetering is door gebruik te maken van KLT multithreading vergeleken met dat van single-threaded processen is er een significante bijkomende snelheidsverbetering door gebruikt te maken van ULT's.  Hoe dan ook, of er nu wel of geen extra snelheidswinst is gerealiseerd hangt af van de aard van de gebruikte programma's. Als de meeste threadwissels in een applicatie kernel modus toegang vereisen, dan zal een ULT-gebaseerd schema niet veel beter presteren dan een KLT-gebaseerd schema.

    4.2.1.3. Gecombineerd

    Sommige besturingssystemen voorzien in een gecombineerde ULT/KLT faciliteit (figuur 4.5c). In een gecombineerd systeem wordt de aanmaak van threads volledig in de gebruikersruimte gedaan, zoals het met de rest van de planning en synchronisatie van threads binnen die applicatie gaat. Meerdere ULT's van een enkele applicatie worden ingedeeld in een (kleiner of gelijk) aantal KLT's. De programmeur kan het aantal KLT's voor een specifieke applicatie en processor aanpassen om zo de beste resultaten te behalen.

    Met een gecombineerde methode kunnen meerdere threads binnen dezelfde applicatie parallel over meerdere processoren lopen en zal een geblokkeerde systeemoproep niet het hele proces blokkeren.  Als het goed ontworpen is zal deze methode de voordelen van zuivere ULT en KLT methodes de nadelen doen minimaliseren.

    Solaris is een goed voorbeeld van een besturingssysteem dat gebruik maakt van deze methode. De huidige Solaris versie limiteert de ULT/KLT relatie tot één-op-één.

    4.2.2. Andere indelingen

    Zoals gezegd. De concepten van brontoewijzing en dispatchingeenheid waren oorspronkelijk omschreven als een enkel concept van een proces, dat is, als een 1:1 relatie tussen threads en processen. Recentelijk is er veel interesse om een proces van meerdere threads te voorzien, welk een veel-tot-één relatie is. Hoewel volgens tabel 4.2 laat zien, zijn de andere relaties ook onderzocht namelijk, de veel-op-veel relatie en de één-op-veel relatie.

    4.2.2.1. Veel-op-veel relaties

    Het idee om veel-tot-veel relaties tussen threads en processen te hebben zijn onderzocht in het experimenteel besturingssysteem TRIX. In TRIX zijn er concepten van een domein en een thread. Een domein is een statische ingang dat een adresruimte en 'poorten' bevat waarlangs berichten gezonden en ontvangen kunnen worden. Een thread is een enkel uitvoerpad met een uitvoerstack, processorstatus en planningsinformatie.

    4.2.2.2. Een-op-veel relaties

    Op het terrein van gedistribueerde besturingssystemen (ontworpen om gedistribueerde computersystemen te besturen) is er interesse geweest in een concept van een thread die hoofdzakelijk als entiteit die zich kan verplaatsen onder de adresruimtes. Een noemenswaardig voorbeeld van dit onderzoek is het Clouds besturingssysteem en voornamelijk zijn kernel, gekend als Ra.

    Een thread in Clouds is een eenheid van activiteit vanuit het standpunt van de gebruiker. Een proces is een virtuele adresruimte met een geassocieerde procescontroleblok. Tijdens de aanmaak, start een thread met uitvoering binnen een proces door in dat proces naar een ingangspunt van dat programma aan te roepen. Threads kunnen zich verplaatsen van de ene adresruimte naar een andere adresruimte en kan zowaar de computergrenzen overbruggen (bv. het verplaatsen van de ene naar de andere computer). Als een thread zich verplaatst, moet bepaalde informatie meenemen, zoals de besturende terminal, globale parameters en planningsrichtlijnen (bv. prioriteiten).

    4.3. SMP

    Traditioneel wordt de computer gezien als een sequentiële machine. De meeste computer programmeertalen vereisen dat de programmeur algoritmes als sequenties van instructies programmeert. Een processor voert programma's uit door de machine instructies één voor één in een sequentie uit te voeren. Iedere instructie wordt uitgevoerd in een sequentie van operaties (fetch instructie, fetch operanden, bewerking uitvoeren, resultaten opslaan).

    Deze manier van kijken naar de computer is niet helemaal waar. Op het niveau van micro-operatie, worden meerdere besturingssignalen op hetzelfde moment gegenereerd. Instructie pipelining, tenminste tot het overlappen van de fetch en het uitvoeren van instructies bestaat al voor lange tijd. Beide zijn voorbeelden van functies die parallel uitgevoerd kunnen worden.

    Zoals de computer technologie is geëvolueerd en de kostprijs van de hardware is gedaald zijn computerontwerpers op zoek gegaan naar opportuniteiten voor parallelisme, gebruikelijk om de prestaties te verbeteren en in sommige gevallen de betrouwbaarheid te verhogen.

    4.3.1. SMP Architectuur

    Het is handig om te zien waar SMP architecturen passen binnen de gehele categorie van parallelle processors.

  • Single instruction single data (SISD) stroom: Een enkele processor voert een enkele instructiestroom uit om de data in het enkele geheugen te besturen.
  • Single instruction multiple data (SIMD) stroom: Een enkele machine instructie bestuurt de simultane uitvoering van een aantal verwerkingselementen op een lockstep basis. Ieder verwerkend element heeft een geassocieerd datageheugen, zodat iedere instructie wordt uitgevoerd op een verschillende set van data door verschillende processoren. Vector en array processoren vallen onder deze categorie.
  • Multiple instructions single data (MISD) stroom: Een sequentie van data wordt verstuurd naar een set van processoren, welke ieder een andere instructiesequentie uitvoert. Deze structuur is nog nooit geïmplementeerd.
  • Multiple instructions multiple data (MIMD) stroom: Een set van processoren voeren simultaan verschillende instructiesequenties uit op verschillende datasets.
  • 4.3.2. SMP Organisatie

    Figuur 4.9 illustreert de algemene organisatie van een SMP. Er zijn meerdere processoren, van welke elk zijn eigen besturingseenheid, rekenkundige eenheid en registers bevat. Iedere processor heeft toegang tot een gedeeld hoofdgeheugen en I/O apparaten door een of andere vorm van een onderling verbonden mechanisme; een gedeelde bus is een gebruikelijke faciliteit. De processoren kunnen onderling met elkaar communiceren door middel van het geheugen (berichten en statusinformatie worden achtergelaten in de gedeelde adresruimte). Het kan voor processoren ook mogelijk zijn signalen direct uit te wisselen. Het geheugen is vaak zo georganiseerd dat meerdere simultane toegang tot blokken van geheugen mogelijk te maken.

    In moderne besturingssystemen hebben processoren in het algemeen op zijn minst één niveau van cachegeheugen dat privé is voor de processor. Het gebruik van cache introduceert een nieuwe ontwerpoverweging. Omdat iedere lokale cache een beeld bevat van een deel van het hoofdgeheugen, als een woord in een cache veranderd wordt, kan dit denkbaar een woord in een andere cache ongeldig maken. Om dit te voorkomen moeten andere processoren gealarmeerd worden als een update plaats heeft gevonden. Dit probleem is ook gekend als het cache coherentie probleem en is typisch gericht op hardware dan op het besturingssysteem.

    4.3.3. Multiprocessor besturingssysteem ontwerp overwegingen

    Een SMP besturingssysteem beheerd de processor en andere computer bronnen zo dat de gebruiker het systeem op dezelfde manier ziet als een Multi programmeerbare uniprocessor systeem. Een gebruiker kan applicaties maken dat gebruik maakt van meerdere processen of meerdere threads binnen een proces zonder te kijken of een enkele processor of meerdere processoren beschikbaar zullen zijn. Dus een multiprocessor besturingssysteem moet alle functies van een multiprogrammering systeem voorzien plus extra kenmerken om meerdere processoren te huisvesten. De kernkwestie van het ontwerp bevat het volgende:

  • Gelijktijdige samenwerkende processen of threads: Kernel routines moeten kunnen inspringen om verschillende processoren toe te staan om dezelfde kernelcode simultaan uit te kunnen voeren. Met meerdere processoren die dezelfde of andere delen van de kernel uitvoeren, moeten kerneltabellen en beheerstructuren fatsoenlijk beheerd worden om deadlocks of ongeldige bewerkingen te vermijden.
  • Planning: Planning kun uitgevoerd worden door elke processor, zodat conflicten vermeden kunnen worden. Als kernelniveau multithreading wordt gebruikt dan zal de kans bestaan om op meerdere processoren, simultaan meerdere threads voor hetzelfde proces te plannen.
  • Synchronisatie: Met meerdere actieve processen die potentiële toegang hebben tot de gedeelde adresruimte of gedeelde I/O bronnen, moet voorzichtigheid genomen worden om te voorzien in effectieve synchronisatie. Synchronisatie is een faciliteit dat wederzijdse uitsluiting en gebeurtenis ordening afdwingt. Een gebruikelijk synchronisatiemechanisme in multiprocessor besturingssystemen gebruikt zijn locks. Deze worden beschreven in hoofdstuk 5.
  • Geheugenbeheer: Geheugenbeheer op een multiprocessor moet omgaan met alle kwesties die op een uniprocessor gevonden zijn en worden besproken in hoofdstuk 3. Het besturingssysteem moet de mogelijkheid om de best mogelijke prestaties te bereiken door de beschikbare hardware parallellen zoals multiported geheugens te benutten.
  • Betrouwbaarheid en fouttolerantie: Het besturingssysteem zou fatsoenlijke degradatie in het zicht van het processor falen moeten voorzien. De planner en andere delen van het besturingssysteem moeten het verlies van een processor herkennen en de beheertabellen als zodanig herstructureren.
  • Omdat multiprocessor besturingssysteem ontwerpkwesties in het algemeen gepaard gaan met de oplossingen van multiprogrammering uniprocessor ontwerp problemen, zullen de we multiprocessor besturingssystemen niet apart behandelen. Echter, specifieke multiprocessorkwesties worden behandeld in de juiste context doorheen dit boek.

    4.4. Microkernels

    Een microkernel is een klein besturingssysteem dat voorziet in de fundatie van modulaire extensies. De term is ietwat vaag, echter, en er zijn een aantal vragen over microkernels dat verschillend beantwoord worden door verschillende ontwerpteams van besturingssystemen. De vragen bevatten hoe klein een kernel moet zijn om te voldoen aan een microkernel, hoe je device drivers moet ontwerpen om de beste prestaties te krijgen terwijl je hun functies abstraheert van de hardware, of het nu om non-kernel operaties uit te voeren in de kernel- of gebruikersruimte en of om de bestaande subsysteemcode te bewaren of om te beginnen vanaf nul.

    De microkernel benadering was populair gemaakt door het gebruik in het Mach OS, welk de nieuwe kern is van de Macintosh Mac OS X besturingssysteem. In theorie voorziet deze aanpak in hoge mate van flexibiliteit en modulariteit. Een aantal producten bezitten nu de microkernel implementatie en deze algemene ontwerp aanpak wordt waarschijnlijk meer en meer gezien in de personal computer, werkstations en server besturingssystemen die in de nabije toekomst ontwikkeld worden.

    4.4.1. Microkernel architectuur

    Besturingssystemen die in het midden tot in de laten jaren van 1950 werden ontwikkeld, waren ontworpen zonder zich bezig te houden met de structuur. Toen had niemand nog ervaring in het bouwen van een echt groot software systeem en problemen die werden veroorzaakt door wederzijdse afhankelijkheid en onderlinge beïnvloeding werden grofweg onderschat. In deze monolithische besturingssystemen, kan praktisch om het even welke procedure een andere procedure oproepen. Zulke tekortkoming in structuur was onhoudbaar zodra besturingssystemen evolueerden tot massieve proporties. Zoals we al behandeld hadden in sectie 2.3 waren modulaire programmeer technieken nodig om te kunnen omgaan met dit niveau van softwareontwikkeling. Meer bepaald, gelaagde besturingssystemen (figuur 4.10a) waren ontwikkeld waarin functies georganiseerd waren volgens een hiërarchie en de interactie enkel plaats vond tussen de naburige lagen. Met de gelaagde methode worden de meeste lagen uitgevoerd in de kernel modus.

    De problemen bleven zelfs met de gelaagde methode. Iedere laag bezat aanzienlijke functionaliteit. Belangrijke veranderingen in één laag kon een aantal moeilijk te traceren effecten hebben op de code in de naburige lagen (erboven en eronder). Als resultaat was het dus moeilijk om op maat gemaakte versies van een basis besturingssysteem te implementeren waarin enkele functies toegevoegd of verwijderd waren. Ook beveiliging was moeilijk in bouwen door hoeveelheid interacties tussen de lagen.

    De onderliggende filosofie van de microkernel is dat alleen absoluut noodzakelijke kern functies  in een besturingssysteem zich zouden moeten bevinden in de kernel. Minder essentiële diensten en applicaties worden op de microkernel gebouwd en deze zullen uitgevoerd worden in de gebruikersmode. Alhoewel wat de scheidingslijn is tussen wat wel en wat niet in de kernel moet zitten varieert van het ene ontwerp tot het andere. Het meest gangbare kenmerk is dat veel diensten dat oorspronkelijk deel van het besturingssysteem waren nu externe subsystemen zijn geworden dat in wisselwerking staat met de kernel en met elkaar; deze bevatten apparaat stuurprogramma's, bestandssystemen, virtuele geheugenbeheerders, windowing systeem en beveiligingsdiensten.

    Een microkernel architectuur vervangt de traditionele verticale gelaagdheid van een besturingssysteem door een horizontale (figuur 4.10b). De externe besturingssysteem componenten zijn geïmplementeerd als server processen; deze staan op gelijke basis met elkaar in verbinding, wat betekend de berichten de microkernel moeten passeren. De microkernel fungeert als een berichtenuitwisselingsdienst; Het valideert berichten, stuurt ze door naar de componenten en staat toegang toe tot de hardware. De microkernel vervult ook een beveiligingsfunctie; het voorkomt de berichten passeren tenzij uitwisseling is toegestaan.

    4.4.2. Voordelen van een microkernel organisatie

    Een aantal voordelen voor het gebruik van microkernels zijn gerapporteerd in de literatuur. Deze bevatten:

  • Uniforme interfaces
  • Uitbreidbaarheid
  • Flexibiliteit
  • Overdraagbaarheid
  • Betrouwbaarheid
  • Ondersteuning van gedistribueerde systemen
  • Ondersteuning van object-georiënteerde systemen
  • Microkernelontwerp legt een uniforme interface op aan aanvragen van processen. Processen moeten zich niet onderscheiden tussen kernelniveau en gebruikersniveau diensten, omdat al van dat soort diensten zijn voorzien om berichten te laten passeren.

    Ieder besturingssysteem zal onvermijdelijk features moeten verwerven dat niet in het huidige ontwerp zit, zodra nieuwe hardware apparaten en nieuwe software technieken ontwikkeld worden. De microkernel architectuur bevorderd deze uitbreidbaarheid, dat het toevoegen van nieuwe services toestaat alsook de voorziening van meerdere diensten in hetzelfde functioneel gebied. Bijvoorbeeld kunnen er meerdere bestandsorganisatiesystemen voor diskettes zijn; iedere organisatie kan geïmplementeerd worden als een gebruikersniveau proces in plaats van om meerdere bestandsdiensten  beschikbaar te stellen in het besturingssysteem. Gebruikers kunnen die dienst kiezen uit de verscheidenheid van diensten dat het beste voorziet in de noden van de gebruiker. Wanneer een nieuwe feature wordt toegevoegd zal met de microkernel architectuur zal het enkel nodig zijn de geselecteerde servers aan te passen of toe te voegen. De impact van nieuwe of aangepaste server is beperkt tot de subset van het systeem. Verder is het niet nodig om de kernel te herbouwen als er modificaties zijn gebeurd.

    Met betrekking tot uitbreidbaarheid van de microkernel architectuur is zijn flexibiliteit. Er kunnen niet alleen nieuwe features aan het besturingssysteem toegevoegd worden, maar ook bestaande features kunnen worden uitgenomen om een kleinere en meer efficiënte implementatie voort te brengen. Een microkernel gebaseerd besturingssysteem hoeft niet noodzakelijk een klein systeem te zijn. De structuur leent zich om een brede waaier aan features om toegevoegd te kunnen worden. Maar niet iedereen heeft, bijvoorbeeld, een hoog niveau van bescherming of gedistribueerde verwerking nodig. Indien een substantieel deel van de features optioneel gemaakt wordt, dan zal het basis product aantrekkelijk zijn voor een grotere groep gebruikers.

    Het bijna monopoly van Intel in vele segmenten van het computerplatform zal onwaarschijnlijk eeuwig voortduren. Dus overdraagbaarheid wordt een aantrekkelijke feature van een besturingssysteem. In de microkernel architectuur zitten alle of op zijn minst de processor-specifieke code in de microkernel. Dus zijn er minder veranderingen nodig zijn om het systeem over te zetten naar een andere processor en hebben de neiging om gepaard te gaan in logische groepen.

    Hoe groeten het software product, hoe moeilijker het is om er zeker van te zijn van zijn betrouwbaarheid. Alhoewel het modulair ontwerp helpt om de betrouwbaarheid te verhogen, kan er grotere winst bereikt worden met een microkernel architectuur. Een kleine microkernel kan rigoureus getest worden. Het gebruik van een klein aantal application programming interfaces (API's) verhoogt de kans om, buiten de kernel, kwaliteitsvolle code voor het besturingssysteem voort te brengen. De systeemprogrammeur heeft een beperkt aantal API's ter beschikking en beperkte manier om, en daardoor ongunstig, met andere systeemcomponenten samen te werken.

    De microkernel leent zich tot gedistribueerde systeemondersteuning, inclusief de door gedistribueerde besturingssystemen gecontroleerde clusters. Als een bericht van een cliënt naar een server proces wordt verzonden, moet het bericht een identificatie van de opvragende service bevatten. Als een gedistribueerd systeem (bv. cluster) geconfigureerd is, zodat alle processen en diensten unieke identificaties hebben, dan zal er effectief een enkel systeembeeld zijn op microkernel niveau. Een proces berichten verzenden zonder dat het weet op welke doelcomputer de dienst zich bevindt. We komen terug op dit punt in de bespreking van gedistribueerde systemen in deel 6.

    Een microkernel architectuur functioneert goed in de context van een object-georiënteerd besturingssysteem. Een object-georiënteerde methode kan zich lenen om het ontwerp van de microkernel en modulaire extensies voor het besturingssysteem te ontwikkelen. Dit geeft als resultaat dat een aantal inspanningen voor het microkernel ontwerp zich verplaatsen in de richting van object oriëntatie. Een veelbelovende methode is om de microkernel architectuur met de OOOS principes te laten samensmelten. Componenten zijn objecten met duidelijk gedefinieerde interfaces die onderling verbonden kunnen zijn om software te vormen in een blok gebouwde manier. Alle interactie tussen componenten gebruiken de component interface. Andere systemen, zoals Windows, welke niet exclusief of volledig op object-georiënteerde methoden steunen, maar wel de object-georiënteerde principes in de het microkernel ontwerp hebben opgenomen.

    4.4.3. Microkernel prestaties

    Een potentieel nadeel van microkernels is de prestatie. Het neemt meer tijd is beslag om een bericht te maken en te versturen via de microkernel en een antwoord aan te nemen en te decoderen, dan om een enkele systeemoproep te maken. Hoewel andere factoren meespelen is het moeilijk om prestatie de veralgemeniseren.

    Veel hangt af van de grootte en functionaliteit van de microkernel. [LIED96a] somt een aantal studies op dat een substantiële prestatie nadeel kenbaar maakt, wat de eerste-generatie microkernels genoemd kunnen worden. Deze nadelen blijven voortduren ondanks de inspanningen om de microkernelcode te optimaliseren. Een antwoord op dit probleem was om de microkernel uit te breiden door kritische servers en stuurprogramma's terug in het besturingssysteem te plaatsen. Het selectief verhogen van de functionaliteit van de microkernel verminderd het aantal gebruikers-kernel modus wissels en het aantal wissels van de procesadresruimte. Hoewel deze omzeiling de prestatie handicap vermindert gaat dit ten koste van de kracht van het microkernel ontwerp: minimale interfaces, flexibiliteit en zo verder.

    Een andere methode is om de microkernel niet groter maar kleiner te maken. [LIED96b] beargumenteerd dat, fatsoenlijk ontworpen, een heel kleine microkernel de prestatie handicap elimineert en de flexibiliteit en betrouwbaarheid verhoogt. Om een idee te geven van de betrokken groottes, bevat de code van een typische eerste-generatie microkernel 300 Kbytes aan code en 140 systeemoproep interfaces. Een voorbeeld van een tweede-generatie microkernel 12 Kbytes aan code en 7 systeemoproepen. Ervaringen met deze systemen tonen aan dat zo even goed zelfs beter kunnen presteren dan een gelaagd besturingssysteem zoals UNIX.

    4.4.4. Ontwerp

    Omdat verschillende microkernels een brede waaier aan functionaliteit en grootte vertonen, kunnen er geen stringente regels worden vastgelegd met betrekking tot welke functies voorzien moeten worden door de microkernel en welke structuur geïmplementeerd is. In deze sectie laten we een minimale set zien van microkernel functies en diensten om een voorbeeld te geven van een microkernel ontwerp.

    De microkernel moet die functies bevatten dat direct afhankelijk is van de hardware en die functies die nodig zijn om de servers en applicaties die in gebruikersmodus werken te ondersteunen. Deze functies vallen in de algemene categorieën van low-level geheugenbeheer, interproces communcatie (IPC), I/O en interrupt beheer.

    4.4.4.1. Low-level geheugenbeheer

    De microkernel met het hardware concept van de adresruimte controleren om het mogelijk te maken om de beveiliging op het procesniveau mogelijk te maken. Zo lang als de microkernel verantwoordelijk is voor het in kaart brengen van iedere virtuele pagina aan een frame, kan het gros van het geheugenbeheer, inclusief de beveiliging van de adresruimte van één proces naar een ander en het algoritme voor de paginavervanging en andere pagineringslogica, buiten de kernel geïmplementeerd worden.

    Het concept dat paginering en virtueel geheugenbeheer extern uitgevoerd kan worden werd geïntroduceerd met de Mach's externe pagineerder [YOUN87]. Figuur 4.11 illustreert de werking van een externe pagineerder. Als een thread in de applicatie naar een pagina verwijst dat niet in hoofdgeheugen zit, treedt een paginafout op en uitvoering zal verdergaan met de kernel. Dan zal de kernel een bericht naar de pagineerproces zenden om aan te geven naar welke pagina was verwezen. De pagineerder kan beslissen om die pagina te laden en voor dat doel een pagina toewijzen. De pagineerder en de kernel moeten samenwerken om de logische bewerkingen van de pagineerder op het fysiek geheugen in kaart te brengen. Eenmaal dat de pagina beschikbaar is zal de pagineerder een bericht tot voortzetting sturen naar de applicatie.

    Deze techniek maakt het voor nonkernel processen mogelijk om bestanden en databases in de gebruikersadresruimtes in kaart te brengen zonder tussenkomst van de kernel. Applicatie-specifieke geheugendeling beleid kan buiten de kernel geïmplementeerd worden.

    [LIED95] stelt een set voor van precies drie microkernelbewerkingen die externe paginering en virtueel geheugenbeheer kan ondersteunen.

  • Overdracht (grant): De eigenaar van een adresruimte (een proces) kan een aantal van zijn pagina's toekennen aan een ander proces. De kernel verwijderd deze pagina's van de overdracht geheugenruimte en wijst deze toe aan het toegewezen proces.
  • Kaart (map): Een proces kan om het even welke pagina in kaart brengen van de geheugenruimte van een ander proces, zodat beide processen toegang hebben tot die pagina's. De creëert gedeeld geheugen tussen de twee processen. De kernel onderhoudt de toewijzing van deze pagina's naar de oorspronkelijke eigenaar maar voorziet een overzicht van toewijzingen om toegang toe te staan door andere processen.
  • Spoelen (flush): Een proces kan om het even welke pagina terugeisen dat toegestaan werd om in kaart gebracht te worden naar andere processen.
  • Om te beginnen wijst de kernel al het beschikbare geheugen als bronnen toe aan een basis systeem proces. Zodra nieuwe processen aangemaakt worden, kunnen pagina's van de oorspronkelijke totale adresruimte toegestaan worden of in kaart gebracht te worden aan het nieuwe proces. Zulke soort schema kan meerdere virtuele geheugenschema's simultaan ondersteunen.

    4.4.4.2. Communicatie tussen processen

    Het basis systeem van communicatie tussen processen en threads in een microkernel besturingssysteem zijn berichten. Een bericht bevat een header, dat het zendend en ontvangend proces identificeert en een body, dat de directe data, een pointer naar een datablok en enige andere controle informatie over dat proces bevat. We kennen aannemen van een IPC dat het gebaseerd op poorten die geassocieerd zijn met processen. Een poort is in wezen voor een specifiek proces bestemde wachtrij van berichten; een proces kan meerdere poorten hebben. Geassocieerd met de poort is een lijst van capaciteiten die aangeeft welke processen kunnen communiceren met dit proces. Poort identiteiten en capaciteiten worden onderhouden door de kernel. A proces kan toegang aan een nieuw proces of aan zichzelf toestaan door een bericht naar de kernel te sturen dat de nieuwe poort mogelijkheid aangeeft.

    Een opmerking over het doorgeven van berichten. Het doorgeven van berichten tussen aparte processen met niet-overlappende adresruimtes gaat gepaard met kopiëren van geheugen naar geheugen en is dus gebonden door de snelheid van het geheugen en zal niet schalen naar processorsnelheden. Huidig onderzoek naar besturingssystemen geeft een interesse weer in thread-gebaseerde IPC en geheugen-delings schema's zoals het opnieuw in kaart brengen (remapping) van een pagina (een enkele pagina gedeeld door meerdere processen).

    4.4.4.3. I/O en interruptbeheer

    Met een microkernel architectuur is het mogelijk om met hardware interrupts om te gaan als berichten en I/O poorten in adresruimtes in te sluiten. De microkernel kan interrupts herkennen, maar kan ze niet afhandelen. Het zal echter een bericht aanmaken voor het gebruikersniveau-programma dat momenteel geassocieerd is met dat interrupt. Dus wanneer een interrupt mogelijk wordt gemaakt, wordt een een specifiek gebruikersniveau-proces toegewezen aan die interrupt en zal de kernel de mapping onderhouden. Het omvormen van interrupts naar berichten moet gedaan worden door de microkernel, maar de microkernel zelf is niet betrokken bij de apparaat specifieke afhandeling.

    Herhalingsvragen

    1. Tabel 3.5 vermeldt standaardelementen van een procesbesturingsblok in een besturingssysteem zonder threads. Welke elementen hiervan behoren tot een threadbesturingsblok en welke tot een procesbesturingsblok in een systeem met multithreading?

      Dit verschilt van systeem tot systeem, maar in het algemeen zijn de bronnen eigendom van het proces en elke thread heeft zijn eigen uitvoeringstoestand. Een paar algemene opmerkingen over elke categorie in Tabel 3.5:
      Procesidentificatie: het proces moet worden geïdentificeerd, maar elke thread in het proces moet zijn eigen identificatiecode hebben.
      Processortoestandsinformatie:
      deze zijn over het algemeen procesgerelateerd;
      Procesbesturingsinformatie
      : planning en toestandsinformatie bevindt vooral op het thread niveau; gegevensstructuren kunnen op beide niveaus voorkomen; communicatie tussen processen kunnen door allebei worden ondersteund; procesprivileges kunnen op beide niveaus; geheugenbeheer is over het algemeen op procesniveau; eigendom en gebruik van bronnen is in het algemeen op het procesniveau.

       
    2. Geef argumenten waarom een moduswisseling tussen threads ‘goedkoper’ kan zijn dan een wisseling tussen processen.

      Er is minder toestandsinformatie bij betrokken.
       
    3. Wat zijn de twee afzonderlijke en in principe onafhankelijke kenmerken die deel uitmaken van het procesconcept?

      Bron eigendom en planning/uitvoering.
       
    4. Geef vier algemene voorbeelden van het gebruik van threads in een multiprocessingsysteem voor één gebruiker.

      Werk op voorgrond en achtergrond;
      asynchrone verwerking;
      uitvoeringssnelheid door parallelle verwerking van gegevens;
      modulaire programmastructuur.

       
    5. Welke bronnen worden in het algemeen gedeeld door alle threads van een proces?

      Adresruimte, bestandsbronnen, uitvoeringsprivileges zijn voorbeelden.
       
    6. Geef drie voordelen van ULT’s ten opzicht van KLT’s.

      1. Een threadwisseling vereist geen privileges van de kernelmodus, omdat alle gegevensstructuren voor het threadbeheer zich bevinden binnen de gebruikersadresruimte van één proces Het proces schakelt daarom voor het beheren van threads niet over op kernelmodus. Dit bespaart de overhead van twee moduswisselingen (van gebruiker naar kernel en van kernel terug naar gebruiker).
      2. De scheduling kan toegesneden zijn op een toepassing. De ene toepassing kan bijvoorbeeld baat hebben bij een eenvoudige schedulingalgoritme met round-robin, terwijl een andere toepassing meer baat heeft bij een algoritme op basis van prioriteiten. De algoritme kan worden aangepast aan de toepassing zonder de onderliggende scheduler van het besturingssysteem te verstoren.
      3. ULT's kunnen worden uitgevoerd op elk besturingssysteem. De ondersteuning van ULT's vereist geen aanpassingen van de onderliggende kernel. De threadbibliotheek is een verzameling van hulpprogramma's op toepassingsniveau die worden gedeeld door alle toepassingen.
       
    7. Geef twee nadelen van ULT’s ten opzichte van KLT’s.
      1. In een doorsnee besturingssysteem leiden de meeste systeemoproepen tot een blokkering. Voert een ULT een systeemaanroep uit, dan wordt daardoor niet alleen die thread geblokkeerd, maar worden alle threads binnen het proces geblokkeerd.
      2. Bij een zuivere ULT-benadering heeft een toepassing met multithreading geen voordeel van multiprocessing. Een kernel wijst maar één proces tegelijk toe aan één processeor. Daarom kan op elk moment maar één thread binnen een proces worden uitgevoerd. We hebben dan als het ware multiprogrammering op toepassingsniveau binnen één proces. Deze multiprogrammering kan weliswaar leiden tot een significante snelheidswinst van toepassingen, maar er zijn ook toepassingen die baat zouden hebben bij de mogelijkheid gedeelten van de code gelijktijdig uit te voeren.

       
    8. Omschrijf het begrip ‘jacketing’.

      Jacketing zet een blokkerende systeemoproep om in een niet-blokkerende systeemoproep met behulp van een I/O-routine op toepassingsniveau die de status van het I/O-apparaat controleert.
       
    9. Omschrijf in het kort de verschillende architecturen die vermeld staan in figuur 4.8.

      SIMD (single instruction, multiple data): één machine-instructie bestuurt 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. Vector- en arrayprocessors behoren tot deze categorie.
      MIMD (multiple instruction, multiple data): een verzameling processors voert tegelijk verschillende instructiereeksen uit met verschillende gegevensverzamelingen.
      Master/slave:
      De kernel van het besturingssysteem wordt altijd op een bepaalde processor uitgevoerd. De andere processors kunnen alleen gebruikersprogramma's en eventeel hulpprogramma's van het besturingssyteem uitvoeren.
      SMP (symmetric multiprocessor): de kernel kan op elke processor uitgevoerd worden en meestal verzorgt elke processor zelf de scheduling van de verzameling van aanwezige processen of threads.
      Cluster
      : Elke processor heeft een eigen geheugen, en een zelfstandige computer.

       
    10. Noem de kernzaken bij het ontwerpen van een SMP besturingssysteem.

      Gelijktijdige samenwerkende processen of threads; planning; synchronisatie; geheugenbeheer; betrouwbaarheid en fouttolerantie.
       
    11. Geef voorbeelden van diensten en functies van een doorsnee monolithisch besturingssysteem die als externe subsystemen kunnen voorkomen bij een systeem met een microkernel.

      Apparaatstuurprogramma's, bestandssystemen, manager voor virtueel geheugen, venstersysteem en beveiligingsdiensten.
       
    12. Noem met een korte toelichting zeven mogelijke voordelen van een ontwerp met een microkernel vergeleken met een monolithische opzet.

      Uniforme interfaces: processen hoeven geen onderscheid te maken tussen diensten op kernelniveau of gebruikersniveau, omdat alle diensten worden verleend via het uitwisselen van berichten.
      Uitbreidbaarheid: vereenvoudigt het toevoegen van nieuwe diensten en het leveren van meervoudige diensten in hetzelfde functionele gebied.
      Flexibiliteit: niet alleen kunnen nieuwe voorzieningen worden toegevoegd aan het besturingssysteem, maar ook kunnen bestaande voorzieningen worden wegelaten voor het maken van een kleinere, meer efficiënte implementatie.
      Overdraagbaarheid
      : het geheel of ten minste een groot deel van de processor-specifieke code zit in de microkernel; daardoor zijn er minder veranderingen nodig voor het aanpassen van het systeem aan een ​​nieuwe processor en zijn veranderingen vaak geordend in logische groepen.
      Betrouwbaarheid: Een kleine microkernel kan uitgebreid worden getest. Het gebruik van een klein aantal Application Programming Interfaces (API's) verhoogt de zekerheid dat de juiste code wordt geproduceerd voor de diensten van het besturingssysteem buiten de kernel.
      Ondersteuning van gedistribueerde systemen: de bericht oriëntatie van microkernel communicatie leent zich voor uitbreiding van gedistribueerde systemen.
      Ondersteuning voor objectgeoriënteerde besturingssystemen (OOOS): een object-georiënteerde benadering kan woden toegepast bij het ontwerpen van de microkernel en het ontwikkelen  van modulaire uitbreidingen van het besturingssysteem.

       
    13. Verklaar het mogelijke nadeel bij een microkernel op het gebied van prestaties.

      Het opstellen en versturen van een bericht en het accepteren en decoderen van het antwoord kost meer tijd dan het uitvoeren van één dienstaanroep.
       
    14. Geef drie functies die naar verwachting zelfs in de meest minimale microkernel van een besturingssysteem aanwezig zullen zijn.

      Deze functies vallen in de algemene categorieën van primitief geheugenbeheer (low-level memory management), communicatie tussen processen (IPC), en I/O- en interruptbeheer.
       
    15. Welke basisvorm heeft de communicatie tussen processen of threads in een besturingssysteem met een microkernel?

      Berichten.

    Probleemvraagstukken

    1. We hebben de volgende twee voordelen genoemd van het gebruiken van meerdere threads binnen een proces: (1) het creëren van een nieuwe thread binnen een bestaand proces kost minder werk dan het creëren van een nieuw proces en (2) de communicatie tussen threads binnen hetzelfde proces is eenvoudiger. Geldt ook dat een contextwisseling tussen twee processen binnen hetzelfde proces minder werk kost dan een contextwisseling tussen twee threads in verschillende processen?
       
    2. Bij een  discussie over voor- en nadelen van ULT’s en KLT’s werd opgemerkt dat bij ULT’s het nadeel is dat het aanroepen van een systeemdienst door een ULT niet alleen die betreffende thread blokkeert maar ook alle andere threads binnen het proces. Waarom is dat?
       
    3. In OS/2 is wat in andere besturingssystemen wordt verstaan onder het concept proces gesplitst in drie afzonderlijke soorten entiteiten: sessies, processen en threads. Een sessie is een verzameling van een of meer processen die verbonden is aan een gebruikersinterface (bijvoorbeeld het toetsenbord, het beeldscherm en de muis). De sessie stelt een interactieve gebruikerstoepassing voor, bijvoorbeeld een tekstverwerkingsprogramma of een spreadsheetprogramma. Dit concept biedt de gebruiker van de personal computer de mogelijkheid meer dan één toepassing te openen en bij elke toepassing een of meer vensters op het scherm te tonen. Het besturingssysteem moet bijhouden welk venster, en daarmee welke sessie, actief is, zodat de toetsenbord- en muisinvoer wordt doorgezonden naar de juiste sessie, Op elk moment bevindt één sessie zich in voorgrondmodus, terwijl andere sessies zich in achtergrondmodus bevinden. Alle toetsenbord- en muisinvoer wordt gericht aan een van de processen van de voorgroüdsessie, zoals aangegeven door de toepassingen. Terwijl een sessie zich in voorgrondmodus bevindt, verzendt een proces dat video-uitvoer genereert, de uitvoer rechtstreeks naar de buffer voor de videohardware en daarmee naar het scherm van de gebruiker. Wordt een sessie verplaatst naar de achtergrond, dan wordt de hardware videobuffer opgeslagen in een logische videobuffer voor die sessie. Bevindt een sessie zich in achtergrondmodus en verwerkt of produceert een van de threads van een van de processen van die sessie schermuitvoer, dan wordt die uitvoer gericht aan de logische videobuffer. Keert de sessie terug naar de voorgrond, dan wordt het scherm bijgewerkt met de huidige inhoud van de logische videobuffer voor de nieuwe voorgrondsessie.
      Het aantal aan processen gerelateerde concepten in OS/2 kan worden verminderd van drie tot twee: schrap de sessies en verbind de gebruikersinterface (het toetsenbord, de muis en het scherm) aan processen. Op elk moment bevindt zich dan één proces in voorgrondmodus. De structuur kan verder worden aangepast door de processen te splitsen in threads.
      1. Welke voordelen gaan verloren bij deze benadering?
         
      2. Als u deze aanpassing toch doorvoert, waar wijst u dan bronnen (geheugen. bestanden enzovoort) toe: op procesniveau of op threadniveau?
         
    4. Ga uit van een omgeving met een één-op-éénafbeelding van threads op gebruikersniveau naar threads op kernelniveau waarin een of meer threads binnen een proces een blokkerende systeemaanroep kunnen gebruiken terwijl de uitvoering van andere threads wordt voortgezet. Leg uit waarom deze opzet programma’s met multithreading sneller kan maken dan hun tegenhangers met één thread op een machine met één processor.
       
    5. Als een proces wordt beëindigd en er worden nog steeds threads van dat proces uitgevoerd, wordt de uitvoering van die threads dan voortgezet?
       
    6. Het besturingssysteem OS/390 voor mainframes is gestructureerd rond de concepten adresruimte en taak. Ruwweg kunnen we zeggen dat één adresruimte overeenkomt met één toepassing en min of meer overeenkomt met een proces in andere besturingssystemen. Binnen een adresruimte kunnen meerdere processen worden gecreëerd en gelijktijdig worden uitgevoerd; dit is min of meer hetzelfde als het concept van multithreading. T\vee gegevensstructuren zijn essentieel voor het beheren van deze processtructuur. Een adresruimtebesturingsblok (address space control block, ASCB) bevat informatie over een adresruimte die OS/390 nodig heeft, ongeacht of die adresruimte wordt uitgevoerd. De informatie in het ASCB bestaat uit de verdelingsprioriteit, het werkelijke en virtuele geheugen dat aan deze adresruimte is toegewezen, het aantal gereed staande processen in deze adresruimte en of deze al of niet zijn geswapt. Een taakbesturingsblok (task control block, TCB) stelt een gebruikers- programma voor dat wordt uitgevoerd. Het bevat informatie die nodig is om een taak te beheren binnen een adresruimte, waaronder informatie over de processorstatus. verwijzingen naar programma’s die deel uitmaken van deze taak en de uitvoeringstoestand van de taak. ASCB’s zijn algemene (global) structuren die worden bijgehouden in het systeemgeheugen en TCB’s zijn lokale structuren die worden bijgehouden in hun adresruimte. Wat is het voordeel van het opsplitsen van de besturingsinformatie in algemene en lokale delen?
       
    7. Aan een multiprocessor met acht processors zijn twintig tapestations (magneetband) verbonden. Het systeem moet een groot aantal taken verwerken, die voor hun afronding elk maximaal vier tapestations nodig hebben. Veronderstel dat de uitvoering van elke taak begint met een lange periode waarin maar drie tapestations nodig zijn, gevolgd door een korte periode aan het einde van de bewerking waarin het vierde tapestation nodig is. Veronderstel bovendien dat het aanbod van dergelijke taken onbeperkt is.
      1. Ga ervan uit dat de scheduler in het besturingssysteem pas begint met een taak als er vier tapestations beschikbaar zijn. Bij het starten van een taak worden onmiddellijk vier stations toegewezen en niet meer vrijgegeven totdat de taak is voltooid. Wat is het maximum aantal taken dat tegelijk kan worden uitgevoerd? Wat is het maximum aantal en het minimum aantal tapestations dat door deze strategie ongebruikt zal blijven?
      2. Formuleer een voorstel voor een alternatieve strategie die het gebruik van de tapestations verbetert en tegelijk een deadlock van het systeem voorkomt. Wat is het maximum aantal taken dat tegelijk kan worden uitgevoerd? Binnen welke grenzen blijven tapestations ongebruikt?
         
    8. Tijdens de beschrijving van de ULT-toestanden van Solaris werd gesteld dat een ULT kan wijken voor een andere thread met dezelfde prioriteit. Is het niet mogelijk dat er ook een thread is met een hogere prioriteit en moet de uitwijkfunctie daarom niet leiden tot wijken voor een thread met gelijke of hogere prioriteit?