Operating Systems Processen

Besturingssystemen Verwerkt de aansluiting, totProcessen

Referenties:

  1. Abraham Silberschatz, Greg Gagne, en Peter Baer Galvin, "Operating System Concepts, negende editie ", Hoofdstuk 3

3.1 Proces Concept

  • Een werkwijze is een voorbeeld van uitvoeringsprogramma.
  • Batch systemen werken op het gebied van "jobs". Veel moderne proces concepten worden steeds uitgedrukt in termen van banen, (bijv. Job scheduling), en de twee termen worden vaak door elkaar gebruikt.

3.1.1 Het proces

  • Werkwijze geheugen is verdeeld in vier secties zoals getoond in figuur 3.1 hieronder:
  • Het tekstdeel omvat de gecompileerde programmacode, gelezen uit niet-vluchtig geheugen wanneer het programma wordt gestart.
  • De data sectie slaat globale en statische variabelen, toegewezen en geïnitialiseerd voorafgaand aan het uitvoeren van de belangrijkste.
  • De hoop wordt gebruikt voor dynamische toewijzing van het geheugen, en wordt beheerd via oproepen om nieuwe, verwijderen, malloc, gratis, enz.
  • De stapel wordt gebruikt voor lokale variabelen. Ruimte op de stack is gereserveerd voor lokale variabelen als ze worden gedeclareerd (in functie ingang of elders, afhankelijk van de taal), en de ruimte wordt vrijgemaakt wanneer de variabelen uit te gaan van de scope. Merk op dat de stapel ook wordt gebruikt voor de functie return waarden, en de exacte mechanismen van de stapel het management kunnen taalfouten specifiek zijn.
  • Merk op dat de stack en de heap vanaf tegenoverliggende einden van vrije ruimte van het proces en te groeien naar elkaar. Als ze ooit zou ontmoeten, dan ofwel een stack overflow fout zal optreden, of anders een oproep om nieuwe of malloc zal mislukken als gevolg van onvoldoende geheugen beschikbaar is.


  • Wanneer processen uit het geheugen worden verwisseld en later hersteld, moet aanvullende informatie ook worden opgeslagen en hersteld. Key onder hen zijn de programma teller en de waarde van alle programma-registers.
  • 3.1.2 Process State

    • Processen kan uit één van 5 toestanden, zoals in figuur 3.2.
    • nieuwe – De werkwijze is in het stadium worden gecreëerd.
    • Klaar – Het proces heeft alle beschikbare middelen die het nodig heeft om te rennen, maar de CPU is niet momenteel aan de instructies van dit proces.
    • hardlopen – De CPU werkt aan de instructies van dit proces.
    • Aan het wachten – De werkwijze kan niet worden uitgevoerd op dit moment, omdat het wachten op een bron beschikbaar of andere gebeurtenis optreedt worden. Bijvoorbeeld het proces kan worden te wachten op invoer van het toetsenbord, toegang tot de schijf verzoek, inter-proces berichten, een timer afgaat, of een kind proces te voltooien.
    • beëindigd – Het proces is voltooid.
  • De gemiddelde belasting van de gerapporteerde "w" opdracht geven het gemiddelde aantal processen in de "Klaar" staat over de laatste 1, 5 en 15 minuten, dat wil zeggen processen die alles wat ze nodig hebben om te draaien, maar kan niet omdat de CPU is bezig iets te doen anders.
  • Sommige systemen kunnen andere staten hebben naast de hier genoemde Ones.
  • 3.1.3 Process Control Block

    Voor elk proces is er procesbesturingsblok, PCB, die de volgende (typen) processpecifieke informatie opslaat, zie figuur 3.1. (Specifieke details kunnen variëren van systeem tot systeem.)

    • Process State – Lopen, wachtend, etc. zoals hierboven besproken.
    • proces-ID. en ouder proces ID.
    • CPU registers en Program Counter – Deze moeten opgeslagen en hersteld bij het uitwisselen van processen in en uit de CPU worden.
    • CPU-Scheduling – Zoals de prioritaire informatie en verwijzingen naar scheduling wachtrijen.
    • Memory-Management informatie – Bijv. pagina tafels of segment tafels.
    • Boekhoudkundige informatie – gebruiker en kernel CPU-tijd verbruikt, rekeningnummers, grenzen, enz.
    • I / O statusinformatie – Apparaten uitgetrokken, open file tafels, enz.

    Dieper: De Linux task_struct definitie in sched.h (Zie ook de top van dat bestand.)

    3.1.4 Threads

    • Moderne systemen maken het mogelijk een enkel proces om meerdere threads van de uitvoering, die tegelijkertijd uitvoert. Draden worden uitgebreid behandeld in het volgende hoofdstuk.

    3.2 Process Scheduling

    • De twee belangrijkste doelstellingen van het proces scheduling systeem om de CPU bezig te houden te allen tijde en te leveren "aanvaardbaar" responstijden voor alle programma’s, in het bijzonder voor interactieve degenen.
    • Het proces scheduler moet deze doelstellingen te verwezenlijken door de uitvoering van geschikt beleid voor het ruilen processen in en uit de CPU.
    • (Merk op dat deze doelstellingen strijdig kan zijn. In het bijzonder telkens wanneer het systeem stappen swap verwerkt deze tijd neemt de CPU te doen, die daardoor "de weg kwijt" van het doen van alle nuttige productief werk. )

    3.2.1 Scheduling Wachtrijen

    • Alle processen worden opgeslagen in het wachtrij.
    • Processen in de status Klaar worden geplaatst in de klaar wachtrij.
    • Processen te wachten voor een apparaat beschikbaar komt of om te leveren gegevens worden in geplaatst apparaat wachtrijen. Er is meestal een afzonderlijk apparaat wachtrij voor elk apparaat.
    • Andere wachtrijen kunnen worden gemaakt en gebruikt indien nodig.

    3.2.2 planners

    • EEN op lange termijn scheduler is kenmerkend voor een batch systeem of een zeer zwaar belast systeem. Het loopt zelden, (zoals wanneer een proces eindigt het selecteren van een meer in te laden van schijf op zijn plaats), en zich kan veroorloven om de tijd om intelligente en geavanceerde algoritmen ten uitvoer te leggen.
    • De kortlopende scheduler. of CPU Scheduler, loopt zeer frequent, in de orde van 100 milliseconden, en moet zeer snel wisselen een proces van de CPU en de swap in een andere.
    • Sommige systemen ook gebruik van een middellange termijn planner. Wanneer het systeem laadt krijgen hoog is, zal deze planner een of meer processen verwisselen van de kant wachtrij voor een paar seconden, zodat kleinere snellere banen om snel af te maken en het systeem te wissen. De verschillen in de figuren 3.7 en 3.8 hieronder.
    • Een efficiënte scheduling systeem zal een goede kiezen proces mix van CPU-bound processen en I / O-gebonden processen.

    3.2.3 Context Switch

    • Wanneer een interrupt komt, moet de CPU een doen state-save van de momenteel lopende proces, schakel dan in de kernel-modus om de interrupt te behandelen, en doe dan een state-herstellen van het onderbroken proces.
    • Ook een ander onderwerp treedt op wanneer de tijdsegment één proces afgelopen en een nieuw proces uit de wachtrij klaar om te worden geladen. Dit zal worden aangezet door een timer interrupt, die vervolgens zal leiden tot toestand het huidige proces is om gered te worden en staat het nieuwe proces om te worden hersteld.
    • Opslaan en herstellen Staten tevens opslaan en herstellen alle registers en programmateller (s), alsmede de procesbesturingsblokken hierboven beschreven.
    • Context omschakeling gebeurt heel erg vaak, en de overhead van het doen van de omschakeling is net verloren CPU-tijd, dus context switches (state bespaart & restores) moet zo snel mogelijk zijn. Sommige hardware heeft speciale voorzieningen voor het versnellen van deze omhoog, zoals een enkele machine instructie voor het opslaan of herstellen van alle registers tegelijk.
    • Sommige Zon hardware heeft eigenlijk meerdere sets van registers, zodat de context switching kan worden versneld door alleen te schakelen welke set registers momenteel in gebruik zijn. Uiteraard is er een limiet aan het aantal processen kan worden geschakeld tussen deze wijze, waardoor zowel uitvoering middellange termijnscheduler sommige processen swap zie figuur 3.8 hierboven.

    3.3 Bewerkingen op Processen

    3.3.1 Process Creation

    • Processen kunnen andere processen door middel van passend systeem aanroepen, zoals het creëren vork of paaien. De werkwijze zorgt voor het creëren wel wordt genoemd het ouder andere werkwijze, die wordt aangeduid als de kind .
    • Elk proces krijgt een integer identifier, genaamd de proces identifier. of PID. De ouder PID (PPID) wordt ook opgeslagen voor elk proces.
    • Op typische UNIX-systemen het proces scheduler wordt genoemd sched. en wordt gegeven PID 0. Het eerste wat het doet bij het opstarten de tijd om te starten in het. waardoor dat proces PID 1. Init lanceert dan alle systeemdaemons en logins, en wordt de uiteindelijke moedermaatschappij van alle andere processen. Figuur 3.9 toont een typische procesboom een ​​Linux-systeem en andere systemen vergelijkbare maar niet identieke bomen:
    • Afhankelijk van de implementatie van het systeem, kan een kind proces een bepaalde hoeveelheid gedeelde bronnen ontvangen met haar moedermaatschappij. Dochterprocessen dan niet beperkt tot een deelverzameling van de middelen aanvankelijk toegewezen aan de ouder, waardoor weggelopen kinderen consumeren al een bepaald systeemelement.
    • Er zijn twee opties voor het bovenliggende proces na het aanmaken van het kind:
      1. Wacht tot het kind-proces te beëindigen voordat u verder gaat. De ouder maakt een wachttijd () system call, voor zowel een specifiek kind of voor elk kind, waardoor de bovenliggende proces te blokkeren totdat het wachten () geeft. UNIX shells normaal wachten op hun kinderen te voltooien alvorens een nieuwe prompt.
      2. Samenvallen met het kind, de voortzetting te verwerken zonder te wachten. Dit is de operatie gezien als een UNIX-shell loopt een proces als een achtergrond taak. Het is ook mogelijk dat de ouder enige tijd draaien en wacht voor het kind later, wat kan optreden in een soort van parallelle verwerking. (Bijvoorbeeld de ouder kan een aantal kinderen vork af zonder te wachten op een van hen, dan een beetje werk van zijn eigen doen, en dan wachten op de kinderen.)
      3. Twee mogelijkheden van de adresruimte van het kind ten opzichte van de ouder:
        1. Het kind kan een exacte kopie van de ouder, het delen van hetzelfde programma en data segmenten in het geheugen. Elk van hen zal een eigen PCB hebben, met inbegrip van het programma teller, registers, en PID. Dit is het gedrag van de vork system call in UNIX.
        2. Het kind proces kan een nieuw programma geladen in de adresruimte, met alle nieuwe code en data segmenten. Dit is het gedrag van de paaien system calls in Windows. UNIX-systemen te implementeren dit als een tweede stap via de exec system call.
        3. De figuren 3.10 en 3.11 hieronder toont de vork en exec proces op een UNIX-systeem. Merk op dat de vork systeem aanroep de PID van de processen kind elk proces – Het levert een nul aan het kind proces en een niet-nul kind PID aan de ouder dat de geretourneerde waarde geeft welke werkwijze die. Proces-id’s kunnen worden opgezocht elk moment voor het huidige proces of haar directe moedermaatschappij met de getpid () en getppid () systeem respectievelijk oproepen.
      4. Figuur 3.12 toont een ingewikkelder werkwijze voor Windows, die alle parameterinformatie voor de nieuwe werkwijze moet als onderdeel van het proces vertakken.
      5. 3.3.2 Process Termination

        • Processen kunnen hun eigen verzoek tot beëindiging van het maken van de Uitgang( ) system call, meestal terug te keren een int. Dit int wordt doorgegeven aan de bovenliggende als het een doet wachten (). en is typisch nul afsluiting en sommige niet nul-code in geval van problemen.
        • kind code:
        • ouder code:
      6. Processen kan ook worden beëindigd door het systeem om verschillende redenen, zoals:
        • Het onvermogen van het systeem benodigde systeembronnen leveren.
        • In antwoord op een KILL opdracht of andere un behandeld proces interrupt.
        • Een ouder kan zijn kinderen te doden als de taak om ze niet langer nodig is.
        • Als de ouder verlaat het systeem al dan niet toestaan ​​dat het kind te blijven zonder ouder. (Op UNIX-systemen, zijn wees processen over het algemeen overgenomen door init, die dan verder om ze te doden. De UNIX nohup commando kan een kind te blijven uitvoeren nadat haar moedermaatschappij heeft verlaten. )
        • Wanneer een proces wordt beëindigd, al zijn systeembronnen worden vrijgemaakt, geopende bestanden gespoeld en gesloten, enz. Het proces beëindiging status en uitvoeringstermijnen worden teruggegeven aan de ouders als de ouder is het wachten op het kind te beëindigen, of uiteindelijk terug naar init als het proces wordt een wees. (Processen die proberen te beëindigen, maar dat kan niet omdat hun ouders niet te wachten tot ze worden genoemd zombies. Deze worden uiteindelijk overgenomen door init als wezen en gedood. Merk op dat de moderne UNIX shells produceren niet zo veel weeskinderen en zombies als oudere systemen gebruikt. )
        • 3.4 interprocescommunicatie

          • Processen onafhankelijke gelijktijdig werken op systemen die niet kunnen beïnvloeden andere processen of worden beïnvloed door andere processen.
          • samenwerkende Processen zijn die kunnen beïnvloeden of beïnvloed door andere processen. Er zijn verschillende redenen waarom samenwerkende processen zijn toegestaan:
          • Het delen van informatie – Er kunnen verschillende processen die de toegang tot hetzelfde bestand bijvoorbeeld nodig. (Bijvoorbeeld pijpleidingen.)
          • Berekening versnelling – vaak een oplossing voor een probleem kan worden sneller opgelost als het probleem kan worden opgesplitst in deeltaken gelijktijdig worden opgelost (met name wanneer meerdere processoren zijn betrokken.)
          • Modulariteit – De meest efficiënte architectuur kan zijn een systeem breken in samenwerkende modules. (Bijvoorbeeld databases met een client-server architectuur.)
          • Gemak – Zelfs een enkele gebruiker kan multitasking, zoals het bewerken, samenstellen, afdrukken en waarop dezelfde code in verschillende vensters zijn.
        • Samenwerkende processen vereisen een soort van inter-proces communicatie, dat is meestal een van de twee types: Gedeeld geheugen systemen of Message Passing systemen. Figuur 3.13 illustreert het verschil tussen de twee systemen:
          • Gedeeld geheugen is sneller als het eenmaal is opgezet, omdat er geen systeem gesprekken nodig zijn en toegang optreedt bij normale geheugen snelheden. Het is echter ingewikkelder op te zetten, en niet zo goed werkt op meerdere computers. Gedeeld geheugen is over het algemeen de voorkeur wanneer grote hoeveelheden informatie snel moet worden gedeeld op dezelfde computer.
          • Message Passing vereist-systeem vraagt ​​om elk bericht de overdracht, en is daarom langzamer, maar het is eenvoudiger in te stellen en werkt goed op meerdere computers. passing bericht het algemeen de voorkeur wanneer de hoeveelheid en / of de frequentie van gegevensoverdracht klein is, of wanneer meerdere computers zijn betrokken.

          3.4.1 Shared-Memory Systems

          • In het algemeen het geheugen worden gedeeld in een gedeelde-geheugensysteem aanvankelijk in de adresruimte van een bepaald proces, dat moet systeem bellen om die algemeen beschikbare geheugen voor een of meer andere processen maken.
          • Andere processen die wensen om de gedeeld geheugen gebruiken moeten dan hun eigen systeem doet denken aan de gedeeld geheugen gebied op hun adresruimte hechten.
          • Over het algemeen een paar berichten moeten heen en weer tussen de samenwerkende processen worden doorgegeven eerste met het oog op het opzetten en coördineren van de gedeelde toegang tot het geheugen.

          Producer-Consumer Voorbeeld met gedeeld geheugen

          • Dit is een klassiek voorbeeld, waarin een werkwijze produceert databank ander proces consumeert data. (In dit voorbeeld in de volgorde waarin het is geproduceerd, hoewel dat kan variëren.)
          • De gegevens worden doorgegeven via een intermediaire buffer, die ofwel ongebonden of gebonden kan zijn. Met een begrensde buffer kan de producent moeten wachten totdat er ruimte beschikbaar is in de buffer, maar met een onbegrensde buffer van de producent zal nooit moeten wachten. De consument kan het nodig zijn om te wachten in ieder geval tot er gegevens beschikbaar.
          • Dit voorbeeld maakt gebruik van gedeeld geheugen en een cirkelvormige wachtrij. Let op in de onderstaande code dat alleen de producent veranderingen "in"En alleen de wijzigingen consument "uit"En dat zij niet kunnen worden bewerkingen op dezelfde locatie matrix tegelijk.
          • Ten eerste zijn de volgende gegevens ingesteld in het gedeelde geheugen gebied:

          #define BUFFER_SIZE 10

          typedef struct lt;
          .
          gt; item;

          punt buffer [BUFFER_SIZE];
          int in = 0;
          int out = 0;

        • Dan is de producent proces. Merk op dat de buffer vol is, wanneer "in" is één minder dan "uit" in een cirkelvormige betekenis:

          // Code uit figuur 3.13

          / * Produce een item en op te slaan in nextProduced * /
          nextProduced = makeNewItem (.);

          / * Wacht tot de ruimte beschikbaar komen * /
          while (((in + 1)% BUFFER_SIZE) == out)
          ; /* Niets doen */

          / * En dan slaan het item en herhaal de lus. * /
          buffer [in] = nextProduced;
          in = (in + 1)% BUFFER_SIZE;

        • Dan is de consument proces. Merk op dat de buffer leeg wanneer "in" is gelijk aan "uit":

          // Code uit figuur 3.14

          / * Wacht voor een item beschikbaar komt * /
          while (in == out)
          ; /* Niets doen */

          / * Klik hier voor de volgende beschikbare artikel * /
          nextConsumed = buffer [out];
          out = (out + 1)% BUFFER_SIZE;

          / * Consumeer het item in nextConsumed
          (Doe iets met het) * /

          3.4.2-Message Passing Systems

          • Message passing systemen moeten ondersteunen bij een minimum-systeem vraagt ​​om "bericht versturen" en "ontvangen bericht".
          • Een communicatieverbinding moet worden gelegd tussen de samenwerkende processen voordat berichten worden verzonden.
          • Er zijn drie belangrijke problemen die moeten worden opgelost message passing systemen verder onderzocht in de komende drie onderafdelingen:
            • Directe of indirecte communicatie (naamgeving)
            • Synchrone en asynchrone communicatie
            • Automatisch of expliciete buffering.
            • 3.4.2.1 Naming
              • Met directe communicatie de afzender moet de naam van de ontvanger waarop zij wil een bericht te sturen weten.
              • Er is een één-op-één relatie tussen elke zender-ontvanger paar.
              • Voor symmetrisch communicatie, moet de ontvanger ook weten de specifieke naam van de afzender van waaruit het wenst te ontvangen.
                Voor asymmetrisch communicatie, is dit niet noodzakelijk.
            • indirecte communicatie maakt gebruik van gedeelde mailboxen of havens.
              • Meerdere processen kunnen dezelfde mailbox of dozen te delen.
              • Slechts één proces kan een bepaald bericht in een mailbox te lezen. Aanvankelijk het proces dat leidt tot de mailbox is de eigenaar, en is de enige toegestaan ​​om mail te lezen in de brievenbus, hoewel dit privilege kunnen worden overgemaakt.
                • (Natuurlijk is het proces dat het bericht leest kan onmiddellijk terug te draaien rond en plaats een identiek bericht in het vak voor iemand anders om te lezen, maar dat kan het op de achterkant van een wachtrij van berichten plaatsen.)
                • Het besturingssysteem moet systeem oproepen om te creëren en brievenbussen te verwijderen, en om berichten naar / verzenden en ontvangen van mailboxen.
                • 3.4.2.2 Synchronisatie
                  • Ofwel het verzenden of ontvangen van berichten (of geen van beide of beide) kan ofwel blokkeren of non-blocking .
                  3.4.2.3 Buffering
                  • Berichten worden doorgegeven via opdrachten, die één van drie configuraties capaciteit kan hebben:
                    1. Zero capaciteit – Berichten kunnen niet worden opgeslagen in de wachtrij, zodat afzenders moet blokkeren tot ontvangers de berichten te aanvaarden.
                    2. begrensde capaciteit – Er is een zekere vooraf bepaalde eindige capaciteit in de wachtrij. Afzenders moeten blokkeren als de wachtrij vol is, tot de beschikbare ruimte in de wachtrij wordt, maar kan onderdrukken of anderszins niet-blokkerende.
                    3. grenzeloze capaciteit – De wachtrij heeft een theoretisch oneindige capaciteit, zodat afzenders worden nooit gedwongen om te blokkeren.

                    3.5 Voorbeelden van IPC Systems

                    3.5.1 Een voorbeeld: POSIX Shared Memory (Achtste editie versie)

                    1. De eerste stap in het gebruik van het gedeelde geheugen is één van de betrokken wat gedeelde geheugen toewijzen, gebruiken shmget processen:

                    int segment_id = shmget (IPC_PRIVATE, grootte, S_IRUSR | S_IWUSR);

                    • De eerste parameter geeft de sleutel (identifier) ​​van het segment. IPC_PRIVATE creëert een nieuw gedeeld geheugen segment.
                    • De tweede parameter geeft aan hoe groot de gedeelde geheugensegment is om, in bytes.
                    • De derde parameter is een set van bitsgewijze ORed vlaggen. In dit geval is het segment wordt gecreëerd voor lezen en schrijven.
                    • De return waarde van shmget is een integer identifier
                  • Elk proces dat wil het gedeelde geheugen gebruiken, moeten de gedeelde geheugen hechten aan hun adres ruimte, met behulp shmat:

                    char * shared_memory = (char *) shmat (segment_id, NULL, 0);

                    • De eerste parameter geeft de sleutel (identifier) ​​van het segment dat het proces wil aan haar adresruimte
                    • De tweede parameter geeft aan waar het proces wenst de segment hebben gehecht. NULL geeft aan dat het systeem moeten bepalen.
                    • De derde parameter is een vlag alleen-leesbewerking. Nul geeft lezen en schrijven; Eén geeft alleen-lezen.
                    • De return waarde van shmat is een leegte *, wat het proces (type cast) kunt gebruiken waar nodig. In dit voorbeeld wordt gebruikt als een karakter pointer.
                    • Vervolgens processen kunnen toegang tot het geheugen via de aanwijzer geretourneerd door shmat, bijvoorbeeld met sprintf:

                      sprintf (shared_memory, "Schrijven naar gedeeld geheugen \ n" );

                    • Wanneer een proces niet langer stuk gedeeld geheugen nodig heeft, kan worden losgemaakt met behulp shmdt:
                    • En ten slotte het proces dat oorspronkelijk toegewezen de gedeeld geheugen kan het uit het systeem aanklagen shmctl verwijderen.

                      shmctl (segment_id, IPC_RMID);

                    • Figuur 3.16 van de achtste editie illustreert een compleet programma tot uitvoering van het gedeelde geheugen op een POSIX-systeem:
                    • 3.5.1 Een voorbeeld: POSIX Shared Memory (negende editie Version)

                      1. De negende editie toont een alternatieve benadering van gedeeld geheugen in POSIX-systemen. Op grond van deze benadering is de eerste stap in het gebruik van gedeeld geheugen is om een ​​gedeeld geheugen object met behulp van shm_open () te maken, op een manier die vergelijkbaar is met andere bestanden te openen commando’s. De opgegeven naam wordt de naam van het geheugen toegewezen bestand. shm_fd = shm_open (naam, O_CREAT | O_RDRW, 0666);
                      2. De volgende stap is de grootte van het bestand ingesteld met ftruncate: ftruncate (shm_fd, 4096);
                      3. Tenslotte is de mmap system call kaarten het bestand naar een geheugen adres in de gebruikersprogramma space.and maakt het gedeeld. In dit voorbeeld is het proces dat schiep de gedeeld geheugen zal schrijven aan toe: ptr = mmap (0, SIZE, PROT_WRITE, MAP_SHARED, shm_fd, 0);
                      4. De "lener" van het gedeeld geheugen (niet degene die het heeft gemaakt), noemt shm_open () en mmap () met verschillende argumenten, slaat de ftruncate () stap en ontkoppelt (verwijdert) de bestandsnaam wanneer het wordt gedaan met het. Merk op dat de "lener" moet dezelfde bestandsnaam als het te gebruiken "geldschieter" wie het heeft gemaakt. (Deze informatie kan zijn doorgegeven met behulp van berichten.) Shm_unlink (naam);
                      5. Merk op dat het schrijven naar en lezen van het gedeelde geheugen wordt gedaan met pointers en geheugenadressen (sprintf) in zowel de 9e en 8e editie versies, terwijl het 9e editie illustreert memory mapping van een bestand.
                      6. De figuren 3.17 en 3.18 van de negende editie illustreren een compleet programma tot uitvoering van het gedeelde geheugen op een POSIX-systeem:

                      3.5.2 Een voorbeeld: Mach

                      • Bedenk dat de Mach kernel is een micro-kernel, waarin naast het leveren van berichten tussen andere taken weinig diensten uitvoert (zowel systeemtaken en gebruikerstaken.)
                      • De meeste communicatie in Mach, met inbegrip van alle system calls en inter-proces communicatie verloopt via berichten naar postbussen, ook wel bekend als de havens.
                      • Wanneer een taak (proces) wordt gemaakt, krijgt het automatisch twee speciale brievenbussen: een Kernel brievenbus en een Hou mailbox.
                      • De kernel communiceert met de taak met behulp van de Kernel mailbox.
                      • De kernel stuurt melding van evenementen om het Houd mailbox.
                    • Drie system calls worden gebruikt voor de overdracht:
                      • msg_send () stuurt een bericht naar een postbus
                      • msg_receive () een bericht ontvangt.
                      • msg_rpc () stuurt een bericht en wacht op precies één bericht respons van de afzender.
                      • Port_allocate () maakt een nieuwe mailbox en de bijbehorende wachtrij voor het houden van berichten (maat 8 standaard ingeschakeld.)
                      • Slechts één taak tegelijk kan eigenaar of berichten ontvangen van een bepaalde mailbox, maar deze zijn overdraagbaar.
                      • Berichten van dezelfde afzender naar dezelfde ontvanger zijn gegarandeerd aan te komen in FIFO volgorde, maar geen garanties zijn gemaakt met betrekking tot berichten van verschillende afzenders.
                      • Bevatten de vaste lengte header gevolgd door variabele lengte data.
                        • De header bevat de mailbox nummer (adres) van de ontvanger en de afzender.
                        • Het onderdeel data bestaat uit een lijst van getypte data-items, die elk een type, grootte en prijs.
                        • Als de mailbox van de ontvanger is vol, de zender heeft vier keuzes:
                          1. Wacht voor onbepaalde tijd totdat er ruimte is in de mailbox.
                          2. Wacht hoogstens N milliseconden.
                          3. Helemaal niet wachten.
                          4. Tijdelijk cache het bericht met de kernel, voor de levering wanneer de mailbox beschikbaar is.
                            • Slechts één zo’n bericht kan afwachting op elk moment van een bepaalde zender naar een bepaalde ontvanger.
                            • Normaal gesproken alleen gebruikt door bepaalde systeem taken, zoals de print spooler, die moet kennis van de "cliënt" van de voltooiing van hun werk, maar kan niet wachten om de mailbox beschikbaar komt.
                            • Gebeld worden moet de brievenbus of mailbox set van waaruit ze willen om berichten te ontvangen op te geven.
                            • Port_status () meldt het aantal berichten te wachten in een bepaalde mailbox.
                            • Als er geen berichten beschikbaar in een mailbox (set), de ontvanger kan ofwel blok voor N milliseconden, of helemaal niet te blokkeren.
                            • Teneinde vertragingen veroorzaakt door het kopiëren van berichten (meerdere keren) voorkomen, Mach opnieuw brengt de geheugenruimte voor het bericht adresruimte de afzender aan adresruimte van de ontvanger (via virtueel geheugen technieken later bedekt) en eigenlijk niet beweegt het bericht waar dan ook. (Wanneer het zenden en ontvangen opdracht beide op dezelfde computer.)
                            • 3.5.3 Een voorbeeld: Windows XP

                              3.6 Communicatie in Client-Server Systems

                              3.6.1 Sockets

                              • EEN stopcontact een eindpunt voor communicatie.
                              • Twee processen communiceren via een netwerk gebruiken vaak een paar aangesloten sockets als communicatiekanaal. Software die is ontworpen voor client-server mogen ook sockets gebruiken voor communicatie tussen twee processen die op dezelfde computer – bijvoorbeeld de UI voor een database programma kan communiceren met de back-end database manager met behulp van sockets. (Als het programma deze manier vanaf het begin ontwikkeld, maakt het zeer gemakkelijk om poort uit één-computersysteem een ​​netwerkapplicatie.)
                              • Een socket wordt aangeduid met een IP-adres aaneengeschakeld met een poortnummer, bijv. 200.100.50.5:80.
                              • Poortnummers onderstaande 1024 worden geacht bekend te zijn. en zijn over het algemeen gereserveerd voor algemene internetdiensten. Bijvoorbeeld, telnet servers luisteren naar poort 23, ftp-servers op poort 21, en webservers op poort 80.
                              • Algemeen doel gebruiker sockets zijn ongebruikte poorten toegewezen via 1024 door het besturingssysteem in reactie op het systeem oproepen zoals socket () of soctkepair ().
                              • Communicatiekanalen via stopcontacten kan van een van de twee belangrijkste vormen zijn:
                              • -Verbinding georiënteerd (TCP, Transmission Control Protocol) verbindingen emuleren een telefoonverbinding. Alle pakketten die worden verzonden langs de verbinding zijn gegarandeerd komen in goede staat aan de andere kant, en te leveren aan de ontvangende proces in de volgorde waarin ze zijn verzonden. De TCP-laag van het netwerkprotocol neemt stappen om alle verzonden pakketten te controleren, opnieuw te verzenden pakketten, indien nodig, en leg de ontvangen pakketten in de juiste volgorde voor hen te leveren aan de ontvangende proces. Er is een zekere mate van overhead betrokken in deze procedure, en als één pakket ontbreekt of vertraagd, dan alle pakketten die volgen zal moeten wachten tot de dwalende pakket wordt geleverd voordat zij hun reis kunnen voortzetten.
                              • Verbindingsloze (UDP, User Datagram Protocol) emuleren individuele telegrammen. Er is geen garantie dat een bepaald pakket door middel van onbeschadigd is (of helemaal niet) te krijgen, en geen garantie dat de pakketten krijgen geleverd in een bepaalde volgorde. Er kunnen zelfs dubbele pakketten geleverd, afhankelijk van de intermediaire verbindingen zijn geconfigureerd. UDP-transmissies zijn veel sneller dan TCP, maar applicaties moeten hun eigen fouten te controleren en recovery procedures te implementeren.
                            • Sockets worden beschouwd als een low-level communicatiekanaal en processen kunnen kiezen vaak om iets te gebruiken op een hoger niveau, zoals die welke in de volgende twee secties.
                            • Figuur 3,19 en 3,20 illustreren een client-server systeem voor het bepalen van de huidige datum via sockets in Java.
                            • 3.6.2 Remote Procedure Calls, RPC

                              • Het algemene concept van RPC is procedure oproepen op dezelfde wijze als een beroep op de gewone lokale procedures, met uitzondering van de procedure ligt op een externe computer wordt genoemd te maken.
                              • implementatie impliceert stubs aan beide zijden van de verbinding.
                              • De lokale proces roept de stomp, net zoals het zou doen op een lokale procedure.
                              • De RPC-systeem pakketten tot (marshals) de parameters om de procedure call, en stuurt ze naar het systeem op afstand.
                              • Op de afstandsbediening kant, de RPC-daemon aanvaardt de parameters en roept de juiste remote procedure om de gevraagde werkzaamheden te verrichten.
                              • Alle resultaten worden geretourneerd worden vervolgens verpakt en door de RPC systeem teruggestuurd naar het lokale systeem, dat dan unpackages hen en stuurt de resultaten naar de lokale aanroepende procedure.
                            • Een potentieel probleem is de opmaak van de gegevens op de lokale versus externe systemen. (Bijv. Big-endian versus little-endian). De oplossing van dit probleem gaat over het algemeen een afgesproken intermediaire formaat, zoals XDR (externe data representatie.)
                            • Een ander probleem is het identificeren welke procedure op het externe systeem een ​​bepaalde RPC is bestemd.
                              • Remote procedures worden geïdentificeerd door poorten. maar niet hetzelfde als de poorten socketpoorten eerder beschreven.
                              • Een oplossing is voor de roeping procedure om het poortnummer ze willen communiceren met op het externe systeem te leren kennen. Dit is problematisch, omdat het poortnummer zou worden opgesteld in de code, en het maakt het af te breken als het systeem op afstand hun poortnummers verandert.
                              • Meer in het algemeen een matchmaker proces wordt toegepast, die fungeert als een telefoon directory service. De lokale proces moet eerst contact opnemen met de matchmaker op het externe systeem (op een bekende poortnummer), die eruit ziet het gewenste poortnummer en geeft het. De lokale proces kan vervolgens die informatie gebruiken om contact op met de gewenste remote procedure. Deze operatie een extra stap, maar is veel flexibeler. Een voorbeeld van de koppelaar werkwijze wordt geïllustreerd in figuur 3.21 hieronder.
                              • Een veelvoorkomend voorbeeld van een systeem op basis van RPC oproepen is een netwerk bestandssysteem. Berichten worden doorgegeven aan lezen, schrijven, verwijderen, hernoemen, of kijk op de status, zoals zou kunnen worden gemaakt voor de gewone lokale schijftoegang verzoeken.
                              • 3.6.3 Pipes

                                • pijpen zijn een van de oudste en meest eenvoudige communicatiekanalen tussen (UNIX) processen.
                                • Er zijn vier belangrijke overwegingen bij de uitvoering van de leidingen:
                                  1. Één of twee richtingen communicatie?
                                  2. Is bidirectionele communicatie half-duplex of full-duplex?
                                  3. Moet een relatie, zoals ouder-kind bestaan ​​tussen de processen?
                                  4. Kan buizen communiceren via een netwerk, of alleen op dezelfde machine?
                                  5. De volgende paragrafen behandelen deze kwesties op UNIX en Windows
                                  3.6.3.1 Gewone Pipes
                                  • Gewone buizen zijn uni-directional, met het lezen van einde en een schriftelijk einde. (Als bidirectionele communicatie nodig zijn, dan is een tweede buis is vereist.)
                                  • In UNIX gewone buizen worden gemaakt met de system call " int pipe (int fd []) ".
                                  • De geretourneerde waarde is 0 op succes, -1 als er een fout optreedt.
                                  • De int array moeten voordat het gesprek worden toegewezen, en de waarden worden ingevuld door het leidingsysteem gesprek:
                                  • fd [0] wordt ingevuld met een file descriptor voor het lezen van de pijp
                                  • fd [1] is ingevuld met een bestand descriptor voor het schrijven van de pijp
                                • UNIX buizen zijn toegankelijk als bestanden, met behulp van standaard read () en write () system calls.
                                • Gewone buizen zijn alleen toegankelijk binnen het proces waarin ze zijn gemaakt.
                                  • Typisch een ouder maakt de pijp voordat forking uit een kind.
                                  • Wanneer het kind erft geopende bestanden van zijn ouder, met inbegrip van de pijp file (s), is een kanaal voor communicatie opgericht.
                                  • Elk proces (ouder en kind) moet eerst sluit de uiteinden van de buis dat ze niet worden gebruikt. Als bijvoorbeeld de ouder schrijft de pijp en het kind leest dan de ouder moet het lezen einde van de pijp sluiten nadat de vork en het kind moet schriftelijk einde sluiten.
                                  • Figuur 3.22 toont een gewone pijp in UNIX en figuur 3.23 toont code waarin het wordt gebruikt.
                                    • Gewone leidingen in Windows zijn zeer vergelijkbaar
                                    • Windows termen hen anoniem pijpen
                                    • Ze zijn nog steeds beperkt tot de ouder-kind relaties.
                                    • Ze worden gelezen en beschreven als bestanden.
                                    • Ze zijn gemaakt met CreatePipe () functie, die extra argumenten neemt.
                                    • In Windows moet worden welke middelen een kind erft, zoals pijpen specificeren.
                                    3.6.3.2 Named Pipes
                                    • Named pipes ondersteunen bidirectionele communicatie, communicatie tussen niet ouder-kind-gerelateerde processen, en doorzettingsvermogen na het proces dat gemaakt hen verlaat. Meerdere processen kunnen ook een named pipe, meestal een lezer en meerdere schrijvers delen.
                                    • In UNIX, named pipes worden genoemd FIFOs, en verschijnen als gewone bestanden in het bestandssysteem.
                                    • (Herkenbaar aan een "p" als het eerste teken van een lange lijst, bijv. / Dev / initctl)
                                    • Gemaakt met mkfifo () en gemanipuleerd met read (), schrijf (), open (), close (). enz.
                                    • UNIX named pipes zijn in twee richtingen, maar half-duplex, dus twee pijpen zijn nog steeds meestal gebruikt voor bidirectionele communicatie.
                                    • UNIX named pipes nog steeds vereisen dat alle processen worden uitgevoerd op dezelfde machine. Anders sockets worden gebruikt.
                                  • Windows named pipes bieden rijkere communicatie.
                                  • Full-duplex wordt ondersteund.
                                  • Processen kunnen op dezelfde of verschillende machines bevinden
                                  • Gemaakt en gemanipuleerd met CreateNamedPipe (), ConnectNamedPipe (), ReadFile () en WriteFile ().
                                  • Race Voorwaarden (Niet uit het boek)

                                    Elke keer dat er twee of meer processen of threads gelijktijdig actief zijn, zijn er mogelijkheden voor een bijzonder moeilijke categorie problemen bekend als race conditions. De identificerende karakteristieke ras voorwaarden is dat de prestaties afhankelijk van welk proces of thread uitvoert voordat ze voor de ander, en dit wordt een probleem wanneer het programma correct wordt uitgevoerd en in sommige gevallen onjuist in andere. Race voorwaarden zijn notoir moeilijk te debuggen, omdat ze onvoorspelbaar, onherhaalbaar, en mogen zich niet vertonen al jaren.

                                    Hier is een voorbeeld waarbij een server en een client communiceren via sockets:

                                    1. Eerst de server schrijft een begroeting aan de klant via het stopcontact:

                                    2. De opdrachtgever leest vervolgens de begroeting in zijn eigen buffer. De klant weet niet zeker hoe lang het bericht is, dus het kent een buffer groter dan het moet zijn. Het volgende zal alle tekens gelezen in de contactdoos, tot maximaal BUFFLENGTH karakters:

                                    3. Nu de server bereidt een pakket van het werk en schrijft dat aan de socket:

                                    4. En tot slot de cliënt leest in het werkpakket en verwerkt deze:

                                    Het probleem: Het probleem ontstaat wanneer de server uitvoert stap 3 voordat de cliënt de mogelijkheid om stap 2, die gemakkelijk kan gebeuren afhankelijk processcheduling voeren had. In dit geval, wanneer de cliënt definitief wordt rond uitvoeren stap 2, dan staat er in niet alleen de oorspronkelijke groet, maar ook het eerste deel van het werkpakket. En alleen maar om de zaken moeilijker te maken om erachter te komen, de cout lt; lt; statement in stap 2 zal alleen afdrukken van de begroeting, want er is een null-byte aan het einde van de begroeting. Dit is eigenlijk zelfs geen probleem op dit punt, maar later wanneer de client stap 4 geactiveerd, niet nauwkeurig gelezen in het werkpakket omdat een deel van het reeds in de buffer uitgelezen in stap 2.

                                    Oplossing I: De makkelijkste oplossing is om de server te schrijven het hele buffer in stap 1, in plaats van alleen het deel gevuld met de groet, zoals:

                                    Helaas is deze oplossing heeft twee problemen: (1) Het verspilt bandbreedte en tijden van schrijven van meer dan noodzakelijk, en belangrijker, (2) Het geeft de code geopend om toekomstige problemen als de BUFFLENGTH niet dezelfde in de client en de server.

                                    Oplossing II: Een betere benadering voor de behandeling variabele lengte snaren eerst de lengte van de tekenreeks, gevolgd door de reeks zelf als een afzonderlijk schrijven schrijven. Onder deze oplossing verandert de server code:

                                    en de client-code als volgt uit:

                                    De hierboven oplossing controleert ook de retourwaarde van het leessysteem oproep om te controleren of het aantal leesbare tekens gelijk is aan het verwachte aantal. (Sommige van deze controles waren eigenlijk in de originele code, maar werden weggelaten uit de toelichting voor de duidelijkheid. De echte code maakt ook gebruik van select () voor het lezen, om te controleren of er personages aanwezig zijn om te lezen en te vertragen, zo niet.)

                                    Merk ook op dat dit probleem niet (gemakkelijk) kan oplossen met de synchronisatietools bedoeld in hoofdstuk 6, omdat het probleem is niet echt een van twee processen toegang tot dezelfde gegevens tegelijkertijd.

                                    3.7 Samenvatting

                                    OLD 3.6.3 Remote Method Invocation, RMI (optioneel, Verwijderd uit 8e editie)

                                    • RMI is de Java implementatie van RPC contact heeft processen die op verschillende Java Virtual Machine, JVM, die al dan niet worden uitgevoerd op een andere fysieke machine.
                                    • Er zijn twee belangrijke verschillen tussen RPC en RMI, beide gebaseerd op het object-georiënteerde karakter van Java:
                                    • RPC toegang op afstand procedures of functies, in een procedureel-programmering paradigma. RMI toegang methoden binnen remote Objects.
                                    • De gegevens die door RPC doorgegeven als functie parameters zijn alleen de gewone gegevens, dat wil zeggen ints, drijvers, verdubbelt, etc. RMI ondersteunt ook het passeren van objecten.
                                  • RMI wordt geïmplementeerd met stubs (op de client) en skeletten (op de servers kant), die verantwoordelijk is voor de verpakking (Marshall) en pak de parameters en retourwaarden heen en weer gevoerd, zoals weergegeven in figuren 3.22 en 3.23:
                                  • Zie de Java online documentatie voor meer details over RMI, waaronder problemen met de waarde ten opzichte van referentie-parameters, en de eisen die bepaalde doorgegeven data items zijn Serializable.
                                  • Bron: www.cs.uic.edu

                                    Geef een reactie

                                    Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

                                    twee × vier =