Distribueret operativsystem - Distributed operating system

Et distribueret operativsystem er systemsoftware over en samling af uafhængige, netværksforbundne , kommunikerende og fysisk separate beregningsnoder. De håndterer job, der serviceres af flere CPU'er. Hver enkelt node har et specifikt softwaredelsæt af det globale samlede operativsystem. Hver delmængde er en sammensætning af to forskellige serviceleverandører. Den første er en allestedsnærværende minimal kerne eller mikrokernel , der direkte styrer nodens hardware. For det andet er en samling på højere niveau af systemadministrationskomponenter, der koordinerer nodens individuelle og samarbejdsaktiviteter. Disse komponenter abstraherer mikrokernelfunktioner og understøtter brugerapplikationer.

Mikrokernel og samling af ledelseskomponenter arbejder sammen. De understøtter systemets mål om at integrere flere ressourcer og behandle funktionalitet i et effektivt og stabilt system. Denne problemfri integration af individuelle noder i et globalt system kaldes gennemsigtighed eller enkelt systembillede ; beskriver illusionen til brugere af det globale systems udseende som en enkelt beregningsenhed.

Beskrivelse

Struktur af monolitisk kerne, mikrokernel og hybrid kerne-baserede operativsystemer

Et distribueret operativsystem leverer de nødvendige tjenester og funktionalitet, der kræves af et operativsystem, men tilføjer attributter og bestemte konfigurationer, så det understøtter yderligere krav såsom øget skala og tilgængelighed. For en bruger fungerer et distribueret operativsystem på en måde, der ligner et monolitisk operativsystem med en enkelt node . Det vil sige, selvom det består af flere noder, ser det ud til brugere og applikationer som en enkelt node.

At adskille minimal systemniveaufunktionalitet fra yderligere modulære moduler på brugerniveau giver en " adskillelse af mekanisme og politik ". Mekanisme og politik kan simpelthen fortolkes som henholdsvis "hvad der gøres" versus "hvordan noget gøres". Denne adskillelse øger fleksibilitet og skalerbarhed.

Oversigt

Kernen

‹ Skabelonen nedenfor ( ekspert nødvendig ) overvejes til sletning. Se skabeloner til diskussion for at hjælpe med at nå til enighed. ›

På hvert sted (typisk en node) tilvejebringer kernen et minimalt komplet sæt hjælpeprogrammer på nodeniveau, der er nødvendige for at drive en nodes underliggende hardware og ressourcer. Disse mekanismer inkluderer allokering, styring og disposition af en knuds ressourcer, processer, kommunikation og input / output management supportfunktioner. Inden for kernen er kommunikationsundersystemet af største betydning for et distribueret operativsystem.

I et distribueret operativsystem, kernen understøtter ofte et minimalt sæt funktioner, herunder lavt niveau adresseområde ledelse, tråd ledelse, og inter-proces kommunikation (IPC). En kerne af dette design kaldes en mikrokernel . Dens modulære karakter forbedrer pålidelighed og sikkerhed, vigtige funktioner til et distribueret operativsystem. Det er almindeligt, at en kerne replikeres identisk over alle noder i et system, og derfor bruger noder i et system lignende hardware. Kombinationen af minimalt design og allestedsnærværende nodedækning forbedrer det globale systems udvidelighed og muligheden for dynamisk at introducere nye noder eller tjenester.

Oversigt over systemstyringskomponenter

Systemadministration

Systemadministrationskomponenter er softwareprocesser, der definerer nodens politikker . Disse komponenter er den del af operativsystemet, der ligger uden for kernen. Disse komponenter giver kommunikation på højere niveau, proces- og ressourcehåndtering, pålidelighed, ydeevne og sikkerhed. Komponenterne matcher funktionerne i et enkelt enhedssystem og tilføjer den nødvendige gennemsigtighed i et distribueret miljø.

OS's distribuerede natur kræver yderligere tjenester for at understøtte en nodes ansvar over for det globale system. Derudover accepterer systemadministrationskomponenterne det "defensive" ansvar for pålidelighed, tilgængelighed og vedholdenhed. Disse ansvarsområder kan være i konflikt med hinanden. En konsekvent tilgang, afbalanceret perspektiv og en dyb forståelse af det samlede system kan hjælpe med at identificere faldende afkast . Adskillelse af politik og mekanisme mildner sådanne konflikter.

Arbejde sammen som et operativsystem

Arkitekturen og designet af et distribueret operativsystem skal realisere både individuelle node- og globale systemmål. Arkitektur og design skal tilgås på en måde, der er i overensstemmelse med adskillelse af politik og mekanisme. Dermed forsøger et distribueret operativsystem at tilvejebringe en effektiv og pålidelig distribueret computerramme, der muliggør en absolut minimal brugerbevidsthed om den underliggende kommando- og kontrolindsats.

Samarbejdet på flere niveauer mellem en kerne og systemadministrationskomponenterne og igen mellem de forskellige noder i et distribueret operativsystem er det distribuerede operativsystems funktionelle udfordring. Dette er det punkt i systemet, der skal opretholde en perfekt harmoni af formålet og samtidig opretholde en fuldstændig afbrydelse af hensigten fra implementeringen. Denne udfordring er det distribuerede operativsystems mulighed for at producere fundamentet og rammen for et pålideligt, effektivt, tilgængeligt, robust, udvideligt og skalerbart system. Denne mulighed har dog meget høje omkostninger i kompleksitet.

Prisen på kompleksitet

I et distribueret operativsystem kunne den usædvanlige grad af iboende kompleksitet let gøre hele systemet til et anathema for enhver bruger. Som sådan skal den logiske pris for at realisere et distribueret operativsystem beregnes ud fra at overvinde enorme mængder af kompleksitet i mange områder og på mange niveauer. Denne beregning inkluderer dybde, bredde og rækkevidde af designinvesteringer og arkitektonisk planlægning, der kræves for at opnå selv den mest beskedne implementering.

Disse hensyn til design og udvikling er kritiske og utilgivende. For eksempel kræves en dyb forståelse af et distribueret operativsystems samlede arkitektoniske og designdetaljer på et usædvanligt tidligt tidspunkt. En udmattende vifte af designovervejelser er iboende i udviklingen af et distribueret operativsystem. Hver af disse designovervejelser kan potentielt påvirke mange af de andre i væsentlig grad. Dette fører til en massiv indsats i afbalanceret tilgang med hensyn til de individuelle designovervejelser og mange af deres permutationer. Som en hjælp i denne indsats er de fleste afhængige af dokumenteret erfaring og forskning i distribueret computerkraft.

Historie

Forsknings- og eksperimentbestræbelser begyndte for alvor i 1970'erne og fortsatte gennem 1990'erne med fokuseret interesse, der toppede i slutningen af 1980'erne. En række distribuerede operativsystemer blev introduceret i denne periode; meget få af disse implementeringer opnåede imidlertid en beskeden kommerciel succes.

Grundlæggende og banebrydende implementeringer af primitive distribuerede operativsystemkomponentkoncepter dateres til begyndelsen af 1950'erne. Nogle af disse individuelle trin var ikke direkte fokuseret på distribueret computing, og på det tidspunkt har mange måske ikke indset deres vigtige indvirkning. Disse banebrydende bestræbelser lagde vigtige grunde og inspirerede til fortsat forskning inden for områder relateret til distribueret computing.

I midten af 1970'erne producerede forskning vigtige fremskridt inden for distribueret computing. Disse gennembrud gav et solidt, stabilt fundament for en indsats, der fortsatte gennem 1990'erne.

Den accelererende spredning af forskning i multi-processor og multi-core processorsystemer førte til en genopblussen af det distribuerede OS-koncept.

1950'erne

DYSEAC

En af de første bestræbelser var DYSEAC , en synkron computer til almindelige formål . I en af de tidligste publikationer fra Association for Computing Machinery , i april 1954, præsenterede en forsker ved National Bureau of Standards - nu National Institute of Standards and Technology ( NIST ) - en detaljeret specifikation af DYSEAC. Introduktionen fokuserede på kravene til de tilsigtede applikationer, herunder fleksibel kommunikation, men nævnte også andre computere:

Endelig kan de eksterne enheder endda omfatte andre computere i fuld skala, der bruger det samme digitale sprog som DYSEAC. For eksempel kunne SEAC eller andre computere, der ligner den, blive udnyttet til DYSEAC, og ved hjælp af koordinerede programmer kunne fås til at arbejde sammen i gensidigt samarbejde om en fælles opgave ... Derfor [,] kan computeren bruges til at koordinere de forskellige aktiviteter af alle eksterne enheder til en effektiv ensembleoperation.

- ALAN L. LEINER, Systemspecifikationer for DYSEAC

Specifikationen diskuterede arkitekturen af multi-computersystemer og foretrak peer-to-peer snarere end master-slave.

Hvert medlem af en sådan sammenkoblet gruppe af separate computere har til enhver tid frihed til at initiere og sende specielle kontrolordrer til nogen af dets partnere i systemet. Som en konsekvens kan overvågningskontrollen over den fælles opgave i første omgang distribueres løst i hele systemet og derefter midlertidigt koncentreret i en computer eller endda gået hurtigt fra den ene maskine til den anden, når behovet opstår. ... de forskellige afbrydelsesfaciliteter, der er beskrevet, er baseret på gensidigt samarbejde mellem computeren og de eksterne enheder, der er datterselskab til den, og afspejler ikke blot et simpelt master-slave-forhold.

- ALAN L. LEINER, Systemspecifikationer for DYSEAC

Dette er et af de tidligste eksempler på en computer med distribueret kontrol. Den Dept. of hæren rapporter certificeret, den er stabil, og at det bestået alle overtagelsesprøverne i april 1954. Den blev færdiggjort og leveret til tiden i maj 1954. Det var en " bærbar computer ", har til huse i en traktor-anhænger , med 2 ledsagende køretøjer og 6 tons kølekapacitet.

Lincoln TX-2

Lincoln TX-2 blev beskrevet som et eksperimentelt input-output-system og understregede fleksible, samtidigt operationelle input-output-enheder, dvs. multiprogrammering . Designet af TX-2 var modulært og understøttede en høj grad af modifikation og udvidelse.

Systemet benyttede Multiple-Sequence Program Technique. Denne teknik tillod flere programtællere til hver tilknytning med en af 32 mulige sekvenser af programkode. Disse eksplicit prioriterede sekvenser kunne sammenflettes og udføres samtidigt, hvilket ikke kun påvirker beregningen undervejs, men også styringsstrømmen af sekvenser og skift af enheder. Meget diskussion relateret til enhedssekventering.

Svarende til DYSEAC kan TX-2 separat programmerede enheder fungere samtidigt og øge kapaciteten . Centralenhedens fulde kraft var tilgængelig for enhver enhed. TX-2 var et andet eksempel på et system, der udviste distribueret kontrol, hvis centrale enhed ikke havde dedikeret kontrol.

Intercommunicating Cells

En tidlig indsats for at abstrahere hukommelsesadgang var Intercommunicating Cells, hvor en celle var sammensat af en samling af hukommelseselementer . Et hukommelseselement var grundlæggende et binært elektronisk flip-flop eller relæ . Inden i en celle var der to typer af elementer, symbol og celle . Hver cellestruktur gemmer data i en streng med symboler, der består af et navn og et sæt parametre . Oplysninger linkes gennem celleforeninger.

Teorien hævdede, at adressering er et spildende og ikke-værdifuldt niveau af indirektion . Der blev adgang til information på to måder, direkte og krydshentning. Direkte hentning accepterer et navn og returnerer et parametersæt. Cross-hentning projekter gennem parametersæt og returnerer et sæt af navne, som indeholder den givne delmængde af parametre. Dette svarede til en modificeret hash-tabel datastruktur, der tillod flere værdier (parametre) for hver nøgle (navn).

Mobilhukommelse ville have mange fordele:
		En stor del af et systems logik distribueres inden for associering af information, der er lagret i cellerne,
		Denne strøm af informationsassociation styres noget af handlingen ved lagring og hentning,
		Den krævede tid til lagring og hentning er for det meste konstant og fuldstændig uden relation til størrelsen og udfyldningsfaktoren for hukommelsen
		Celler kan ikke skelnes logisk, hvilket gør dem både fleksible at bruge og relativt enkle at udvide i størrelse

Denne konfiguration var ideel til distribuerede systemer. Projektionen med konstant tid gennem hukommelse til lagring og hentning var iboende atomær og eksklusiv . Den cellulære hukommelses iboende fordelte egenskaber ville være uvurderlige. Virkningen på bruger- , hardware / enhed eller applikationsprogrammeringsgrænsefladerne var indirekte. Forfatterne overvejede distribuerede systemer med angivelse af:

Vi ønskede at præsentere her de grundlæggende ideer til et distribueret logiksystem med ... det makroskopiske koncept for logisk design, væk fra scanning, fra søgning, fra adressering og fra optælling, er lige så vigtigt. Vi skal for enhver pris frigøre os fra byrderne ved detaljerede lokale problemer, som kun passer til en maskine, der er lav på maskinens evolutionære skala.

- Chung-Yeol (CY) Lee, kommunikationsceller , basis for en distribueret logikcomputer

Grundlæggende arbejde

Sammenhængende hukommelsesabstraktion

Algoritmer til skalerbar synkronisering på delt-hukommelse multiprocessorer

Abstraktion af filsystem

Målinger af et distribueret filsystem
Hukommelsessammenhæng i delte virtuelle hukommelsessystemer

Transaktion abstraktion

Transaktioner
Sagas

Transaktionsbeslutning Memory
kombinerbare hukommelse transaktioner
Transaktionsbeslutning hukommelse: arkitektonisk støtte til lock-fri datastrukturer
Software transaktionsbeslutning hukommelse til dynamisk størrelse datastrukturer
Software transaktionsbeslutning hukommelse

Persistens abstraktion

OceanStore: en arkitektur til vedvarende lagring på global skala

Koordinator abstraktion

Vægtet afstemning for replikerede data
Konsensus i nærvær af delvis synkronisering

Abstraktion pålidelighed

Sanity checks
De byzantinske generaler Problem
fail-stop processorer: en tilgang til design af fejltolerante computersystemer

Gendannelsesbarhed Distribuerede snapshots: bestemmelse af globale tilstande for distribuerede systemer Optimistisk gendannelse i distribuerede systemer

Distribuerede computermodeller

Tre grundlæggende distributioner

For bedre at illustrere dette punkt skal du undersøge tre systemarkitekturer ; centraliseret, decentraliseret og distribueret. I denne undersøgelse skal du overveje tre strukturelle aspekter: organisering, forbindelse og kontrol. Organisation beskriver et systems fysiske arrangementskarakteristika. Forbindelse dækker kommunikationsveje mellem noder. Control styrer driften af de to tidligere overvejelser.

Organisation

Et centraliseret system har et niveau af struktur, hvor alle bestanddele er direkte afhængige af et enkelt kontrolelement. Et decentraliseret system er hierarkisk. Det nederste niveau forener undersæt af et systems enheder. Disse enhedsundersæt kombineres igen på højere niveauer, der i sidste ende kulminerer med et centralt masterelement. Et distribueret system er en samling af autonome elementer uden niveaubegreb.

Forbindelse

Centraliserede systemer forbinder bestanddele direkte til en central masterenhed på en hub- og tale-måde. Et decentraliseret system (aka netværkssystem ) inkorporerer direkte og indirekte stier mellem bestanddele og den centrale enhed. Dette er typisk konfigureret som et hierarki med kun en korteste sti mellem to elementer. Endelig kræver det distribuerede operativsystem intet mønster; direkte og indirekte forbindelser er mulige mellem to elementer. Overvej 1970'ernes fænomener " strengekunst " eller en spirograftegning som et fuldt tilsluttet system , og edderkoppens web eller Interstate Highway System mellem amerikanske byer som eksempler på et delvist forbundet system .

Styring

Centraliserede og decentrale systemer har styret strømmen af forbindelse til og fra den centrale enhed, mens distribuerede systemer kommunikerer langs vilkårlige stier. Dette er den afgørende forestilling om den tredje overvejelse. Kontrol indebærer tildeling af opgaver og data til systemelementer, der balancerer effektivitet, lydhørhed og kompleksitet.

Centraliserede og decentrale systemer giver mere kontrol, hvilket muligvis letter administrationen ved at begrænse mulighederne. Distribuerede systemer er vanskeligere at udtrykkeligt kontrollere, men skaleres bedre vandret og giver færre punkter for systemomspændende fejl. Foreningerne imødekommer de behov, der stilles af dens design, men ikke af organisatorisk kaos

Designhensyn

Gennemsigtighed

Gennemsigtighed eller enkelt-systembillede refererer til evnen til et program til at behandle det system, som det fungerer på, uden hensyn til om det distribueres og uden hensyn til hardware eller andre implementeringsoplysninger. Mange områder i et system kan drage fordel af gennemsigtighed, herunder adgang, placering, ydeevne, navngivning og migration. Hensynet til gennemsigtighed påvirker direkte beslutningstagningen i alle aspekter af designet af et distribueret operativsystem. Gennemsigtighed kan pålægge andre designhensyn visse krav og / eller begrænsninger.

Systemer kan valgfrit krænke gennemsigtigheden i varierende grad for at imødekomme specifikke applikationskrav. For eksempel kan et distribueret operativsystem præsentere en harddisk på en computer som "C:" og et drev på en anden computer som "G:". Brugeren kræver ikke noget kendskab til enhedsdrivere eller drevets placering; begge enheder fungerer på samme måde set fra applikationens perspektiv. En mindre gennemsigtig grænseflade kan kræve, at applikationen ved, hvilken computer der er vært for drevet. Gennemsigtighedsdomæner:

Placeringsgennemsigtighed - Placeringsgennemsigtighed omfatter to forskellige aspekter af gennemsigtighed, navngivning af gennemsigtighed og brugermobilitet. Navngivning af gennemsigtighed kræver, at intet i de fysiske eller logiske referencer til nogen systemenhed skal afsløre nogen indikation af enhedens placering eller dets lokale eller eksterne forhold til brugeren eller applikationen. Brugermobilitet kræver konsekvent henvisning af systemenheder, uanset hvilken systemplacering referencen stammer fra.
Adgangsgennemsigtighed - Lokale og eksterne systemenheder skal forblive skelnes, når de ses gennem brugergrænsefladen. Det distribuerede operativsystem opretholder denne opfattelse gennem eksponering af en enkelt adgangsmekanisme for en systemenhed, uanset om denne enhed er lokal eller fjern for brugeren. Åbenhed dikterer, at enhver forskel i metoder til at få adgang til en bestemt systemenhed - enten lokal eller ekstern - skal være både usynlig for og ikke detekterbar af brugeren.
Migrationsgennemsigtighed - Ressourcer og aktiviteter migrerer fra et element til et andet, der udelukkende kontrolleres af systemet og uden bruger- / applikationsviden eller handling.
Replikering gennemsigtighed - Processen eller det faktum, at en ressource er blevet duplikeret på et andet element, sker under systemkontrol og uden bruger / applikationsviden eller intervention.
Samtidig gennemsigtighed - Brugere / applikationer er uvidende om og påvirkes ikke af andre brugers tilstedeværelse / aktiviteter.
Fejlgennemsigtighed - Systemet er ansvarlig for afsløring og afhjælpning af systemfejl. Ingen brugerkendskab / handling er involveret bortset fra at vente på, at systemet løser problemet.
Performance Transparency - Systemet er ansvarlig for påvisning og afhjælpning af lokale eller globale mangler ved ydeevne. Bemærk, at systempolitikker måske foretrækker nogle brugere / brugerklasser / opgaver over andre. Ingen brugerkendskab eller interaktion. er involveret.
Størrelse / skala gennemsigtighed - Systemet er ansvarlig for styring af dets geografiske rækkevidde, antal noder, niveau for nodefunktioner uden nogen krævet brugerkendskab eller interaktion.
Gennemsigtighed i revisionen - Systemet er ansvarlig for opgraderinger og revisioner og ændringer af systeminfrastrukturen uden brugerens viden eller handling.
Kontroller gennemsigtighed - Systemet er ansvarligt for at levere al systeminformation, konstanter, egenskaber, konfigurationsindstillinger osv. I et ensartet udseende, konnotation og denotation til alle brugere og applikationer.
Datatransparens - Systemet er ansvarligt for at levere data til applikationer uden brugerens viden eller handling vedrørende det sted, hvor systemet gemmer det.
Parallelismetransparens - Systemet er ansvarlig for at udnytte enhver evne til at parallelisere udførelse af opgaver uden brugerens viden eller interaktion. Formentlig det sværeste aspekt af gennemsigtighed og beskrevet af Tanenbaum som den "hellige gral" for distribuerede systemdesignere.

Inter-proces kommunikation

Inter-Process Communication (IPC) er implementeringen af generel kommunikation, procesinteraktion og dataforløb mellem tråde og / eller processer både inden for en node og mellem noder i et distribueret OS. Kravene til kommunikation mellem noder og mellem noder driver IPC-design på lavt niveau, hvilket er den typiske tilgang til implementering af kommunikationsfunktioner, der understøtter gennemsigtighed. I denne forstand er interprocess-kommunikation det største underliggende koncept i lavt niveau design overvejelser i et distribueret operativsystem.

Processtyring

Processtyring giver politikker og mekanismer til effektiv og effektiv deling af ressourcer mellem distribuerede processer. Disse politikker og mekanismer understøtter operationer, der involverer tildeling og deallokering af processer og porte til processorer såvel som mekanismer til at køre, suspendere, migrere, standse eller genoptage procesudførelse. Mens disse ressourcer og operationer enten kan være lokale eller fjerne med hensyn til hinanden, opretholder det distribuerede operativsystem tilstand og synkronisering over alle processer i systemet.

Som et eksempel er belastningsafbalancering en almindelig processtyringsfunktion. Load balancing overvåger node ydeevne og er ansvarlig for at flytte aktivitet på tværs af noder, når systemet er ude af balance. En belastningsbalanceringsfunktion er at vælge en proces, der skal flyttes. Kernen kan anvende flere markeringsmekanismer, herunder prioritetsbaseret valg. Denne mekanisme vælger en proces baseret på en politik som 'nyeste anmodning'. Systemet implementerer politikken

Ressourcestyring

Systemressourcer såsom hukommelse, filer, enheder osv. Distribueres overalt i et system, og på ethvert givet tidspunkt kan en hvilken som helst af disse noder have let til inaktiv arbejdsbelastning. Belastningsdeling og belastningsafbalancering kræver mange politiske orienterede beslutninger, lige fra at finde ledige CPU'er, hvornår de skal flytte, og hvilke de skal flytte. Der findes mange algoritmer til at hjælpe med disse beslutninger; dette kræver imidlertid et andet niveau af beslutningstagningspolitik ved valg af algoritme, der er bedst egnet til scenariet, og forholdene omkring scenariet.

Pålidelighed

Distribueret operativsystem kan levere de nødvendige ressourcer og tjenester for at opnå høje niveauer af pålidelighed eller evnen til at forhindre og / eller komme sig fra fejl. Fejl er fysiske eller logiske defekter, der kan forårsage fejl i systemet. For at et system skal være pålideligt, skal det på en eller anden måde overvinde de ugunstige virkninger af fejl.

De primære metoder til håndtering af fejl inkluderer fejlundgåelse , fejltolerance og fejldetektion og gendannelse . Fejlundgåelse dækker proaktive foranstaltninger truffet for at minimere forekomsten af fejl. Disse proaktive foranstaltninger kan være i form af transaktioner , replikering og sikkerhedskopier . Fejltolerance er et systems evne til at fortsætte driften i nærvær af en fejl. I tilfælde af at systemet skal registrere og gendanne fuld funktionalitet. Under alle omstændigheder bør enhver udført handling gøre alt for at bevare det enkelte systembillede .

Tilgængelighed

Tilgængelighed er den brøkdel af tid, hvorunder systemet kan svare på anmodninger.

Ydeevne

Mange benchmark-målinger kvantificerer ydeevne ; gennemløb, responstid, jobafslutning pr. tidsenhed, systemudnyttelse osv. Med hensyn til et distribueret operativsystem destilleres ydeevne ofte til en balance mellem procesparallelisme og IPC. Styring af opgaven granulariteten af parallelitet i en fornuftig relation til de meddelelser, der kræves til støtte er yderst effektiv. Det er også effektivt at identificere, hvornår det er mere fordelagtigt at migrere en proces til dens data i stedet for at kopiere dataene.

Synkronisering

Samarbejdende samtidige processer har et iboende behov for synkronisering , som sikrer, at ændringer sker på en korrekt og forudsigelig måde. Tre grundlæggende situationer, der definerer omfanget af dette behov:

en eller flere processer skal synkroniseres på et givet punkt for at en eller flere andre processer kan fortsætte,
en eller flere processer skal vente på en asynkron tilstand for at fortsætte,
eller en proces skal etablere eksklusiv adgang til en delt ressource.

Forkert synkronisering kan føre til flere fejltilstande, herunder tab af Atomicity, konsistens, isolation og holdbarhed , dødvande , livelock og tab af serializability .

Fleksibilitet

Fleksibilitet i et distribueret operativsystem forbedres gennem modulet og karakteristika for det distribuerede operativsystem og ved at levere et rigere sæt af tjenester på højere niveau. Fuldstændigheden og kvaliteten af kernen / microkernel forenkler implementeringen af sådanne tjenester og muligvis giver tjenesteudbydere større valg af udbydere til sådanne tjenester.

Forskning

Replikeret model udvidet til en komponentobjektmodel

Arkitektonisk design af E1-distribueret operativsystem
Cronus-distribuerede operativsystem
Design og udvikling af MINIX-distribueret operativsystem

Kompleksitet / tillidseksponering gennem accepteret ansvar

Skala og ydeevne i Denali-isoleringskernen.

Multi / mange-kernefokuserede systemer

Multikernen: en ny OS-arkitektur til skalerbare multicore-systemer.

Corey: et operativsystem til mange kerner.

Almos: Avanceret lokalitetsstyringsoperativsystem til cc-NUMA mange kerner.

Distribueret behandling over ekstremer i heterogenitet

Helios: heterogen multiprocessing med satellitkerner.

Effektiv og stabil i flere niveauer af kompleksitet

Tessellation: Space-Time Partitionering i et Manycore Client OS.

Languages

In other projects