Dataprogrammet som gir maskinene handlekraft
Opp
- Innhold
Tenk deg at du er
på fjelltur sammen med gode venner; vidda
er flott; mobiltelefonen gir god dekning. På hotellet dere har som base
er det installert
brannvarsling i alle rom; dere kom dit i drosje, men tok tog hjemmefra.
Dere er omgitt av
natur på alle kanter, men hadde ikke kommet langt om ikke
mobiltelefonen, brannvarslinga,
datamaskinen i drosjen og styringssystemet på toget hadde hatt
fungerende operativsystem,
et innebygd dataprogram som passer på og tilbyr tjenester til de andre
programmene i
utstyret. PC'en står igjen på hotellrommet, men operativsystemet dens
har nok lagt den i
dyp dvale for å spare strøm.
Her skal jeg prøve å gi en smakebit på hva et operativsystem er. La meg fortsette på fjellet: Dere kommer til et bredt elvefare og må over. I mellomtiden har tåka tetnet til, og mobiltelefonen har ikke dekning. Tåka ligger tjukk; dere kan ikke en gang se over til den andre siden av elva. Elva går stri, men det er en del steiner som dere kan balansere over på. En av dere kjenner stedet, og mener at dere kan komme dere over her. Du går først. Til å begynne med ser det ut til at alt går bra, men så oppdager du at det kommer noen andre fra motsatt side. Dere har ikke hørt dem, før dere ser dem. Idet du skal dele den neste steinen med ham som kommer imot, tar begge tak i hverandre – og dere plumper uti. Dere grep fort tak i den andre i håp om at der var det hold, til begges skuffelse.
Denne fortellingen viser flere problemer som operativsystemene skal håndtere. Steinene er såkalte delte ressurser; det går bra så lenge man kan ha dem for seg selv. Dere ventet, og gikk etter hverandre over elva, og dannet dermed en kø. Kanskje tok dere spesielt hensyn til den eldste, yngste eller minst erfarne idet dere skulle over. Dere lagde et skjema for prioritet. Og når du og han som kom imot deg forventet det samme av hverandre og ikke kunne gå videre før begge hadde fått hold, krevdes det mer enn dere greide. Der kan jeg vel si at dere kom i vranglås. Videre kunne du ikke vite at en annen fot skulle komme ut av tåka og trå på steinen din. Aktiviteten var skjult eller innkapslet for motsatt part. Jeg skal prøve å forklare disse begrepene: delte ressurser, køer, prioritet, vranglås og innkapsling – og se hva de kan bety i en helt annen sammenheng.
Et operativsystem [1] er et dataprogram som startes opp før alle andre programmer som skal kjøre i maskinen – og som kjører hele tiden. Har du PC heter nok operativsystemet Windows. Dette har gjort Microsoft til et av verdens mektigste firmaer. Kanskje heter det Linux, eller Unix, eller Mac OS. Men i mobiltelefonen, bilen, brannvarslingssystemet eller i styringssystemet på toget er operativsystemene mer anonyme.
La oss se på brannvarslingssystemet, et slikt som de har i hoteller, skoler, sykehus, på skip eller offshore. Opp til ett hundre røykvarslere er koblet sammen i en ledningssløyfe, og mellom en sløyfe og selve brannsentralen sitter en enhet som har en ganske liten mikroprosessor. Også i slike små enheter finnes som oftest et lite operativsystem. Enheten har flere dataprogrammer liggende klar når den blir skrudd på. Et av programmene sender elektriske signalpulser til røykvarslerne og forsikrer seg om at ledningssløyfa er fri for brudd, og at røykvarslerne hver for seg svarer når de blir adressert. Et annet av disse programmene tolker signalene og finner ut om det er brann under utvikling. Samtidig skal feilkilder elimineres så godt som mulig. Et tredje program sender resultatet opp til en kraftigere mikroprosessor i selve brannsentralen, som også har et innebygd operativsystem. Om man ikke deler opp, til og med ganske små system, i enda mindre og enklere dataprogrammer, under kontroll av et operativsystem, ville det ha vært vanskeligere å lage et sikkert og fungerende brannvarslingssystem. Operativsystemet hjelper oss med å dele ressurser fra så enkle ting som blinkende lysdioder til å sende meldinger mellom programmene.
La meg forsøke å si litt om hva et dataprogram er. Når du skal til byen, har du kanskje med deg en liste over hva du skal gjøre, som du kan ha notert på i flere dager. Gjøremålene utføres ved at du etter tur deler ut oppgaver til deg selv. Omtrent på samme måten henter en datamaskin instruksjoner om hva den skal foreta seg. En slik instruksjonsliste kalles et dataprogram, og det vil ofte være mange slike program i hver maskin. Disse programmene må være inni maskinen, enten på harddisken, disketten, ferdig preget inn i elektroniske kretser, eller lastet ned fra internett. Å lage slike programmer kalles å programmere; en person som lager dem kalles programmerer, og han eller hun bør beherske et eller flere programmeringsspråk. Programmene blir oversatt til millioner av små beskjeder som maskinens prosessor "skuffer innpå". Når et spesielt program behandles på denne måten, sier vi at det "kjører".
Operativsystemet lever sitt liv blant andre dataprogram; det begynner å kjøre når du skrur på enheten, og kjører hele tiden. Selv om det aldri stopper, er det lagd slik at det skal belaste datamaskinen så lite som mulig. Det er ikke veldig galt å si at operativsystemet bruker omtrent én prosent av maskinens datakraft. En av de sentrale oppgavene et operativsystem har er å håndtere at flere programmer kan kjøre tilsynelatende samtidig. At flere programmer kjører på denne måten kalles fleroppgavekjøring, og det er operativsystemet som er dirigenten. Det må både passe på at det kjører selv, og at andre dataprogram som ønsker det, får kjøre.
Siden flere programmer skal kunne kjøre samtidig, må de – som alle andre som ønsker å få noe gjort – samarbeide om delte ressurser som printer, tastatur, harddisk, mus eller skjerm. Hvordan kan så flere samtidige dataprogrammer dele på felles ressurser? Det var nederlenderen E.W. Dijkstra som på 1960-tallet først kom med løsning på hvordan dataprogrammer pent og pyntelig kan lære seg å vente på tur.
Kanskje har du en trappevender hjemme? Hensikten med den er at du skal kunne skru lyset av og på i begge etasjer, slik at det lyser bare når du er i trappa. Derfor er det en bryter oppe og en nede, og du må innom begge bryterne når du skifter etasje. Lyset i trappa er en delt ressurs. Problemet kommer om en annen person er i motsatt etasje og skal motsatt vei. Du rekker å skru på lyset først, men et kvart sekund etterpå forsøker den andre også å skru på lyset. Resultatet ble at hun skrudde lyset av i stedet for på! Vi fikk det man kaller et res i dataverdenen, og resultatet ble feil.
Det er nå vi trenger Dijkstras oppfinnelse. Han oppdaget at om man lagde en data-ekvivalent for en nøkkel, kunne den løse problemene med hvordan man skulle få tildelt og holde på rettigheten til å benytte en delt ressurs. Dijkstra kalte oppfinnelsen sin for en semafor. Navnet kjenner du kanskje igjen fra de signaliseringsflaggene eller -systemene som tidligere ble benyttet av forsvaret, til sjøs eller på jernbanen. Enten er flagget oppe eller ikke; enten eier man data-semaforen eller ikke; enten så har man nøkkelen eller ikke. Enten har man lov å slå på lyset, eller så har man det ikke.
Det var relativt enkelt å beskrive hvordan en semafor skulle fungere når det var to som skulle dele på én felles ressurs. Men tenk deg et stort trapperom med mange innganger og mange trappebrytere men bare én felles lyskurs. Situasjonen ville bli umulig om det vare mye trafikk i trappene. En løsning kan være å installere trykknapper i stedet. Hvert trykk får lyset til å stå på i ti sekunder. Dette er bra nok, men det kan medføre at enkelte som går sakte i trappa må gå litt i mørke. Så øker vi tiden litt, men regner likevel med at de som setter seg ned midt i trappa kan sitte der i mørke etter en stund. Løsningen er fortsatt bra nok, men ikke 100 prosent bra.
Men semaforløsningen kunne ikke være omtrentlig eller bare bra nok. Dijkstra beskrev en oppskrift som var 100 prosent riktig for et vilkårlig antall brukere eller dataprogrammer. Løsningen var at han måtte sikre seg at maskinen i løpet av et bestemt tidsintervall ikke ville legge et program midlertidig unna og la et annet få slippe til. Når du skal parkere og har puttet pengene på parkeringsautomaten, er det bare rett at du også tar kvitteringen; ingen andre får snappe den fra deg. Innenfor dataterminologien kalles dette en "udelelig test-og-sett instruksjon". Når du kjører programmene dine hjemme, og skal lage en utskrift fra internett og tekstbehandleren samtidig, kan operativsystemet benytte semaforer til å sørge for at du får ut to fine utskrifter, ikke et rot av bokstaver og bilder fra hvert dokument.
En stor del av de problemene som oppstår med operativsystemer, er feil som har med deling av ressurser å gjøre. Hvor ofte har ikke stafettløpere måttet se seg slått fordi de ikke var flinke nok til å gi fra seg eller ta tak i stafettpinnen under et løp? De har synkroniseringsproblemer. På samme måte er det med dataprogrammene som løper stafett etter hverandre. Om de glemmer å frigi en bestemt semafor, kan deler av systemet stoppe opp. For en semafor skal man alltid gi fra seg etter at man har brukt den ressursen som semaforen "beskytter". Printeren har sin egen printersemafor, og blir den ikke frigitt etter utskriften, blir det nok ikke flere utskrifter før maskinen blir startet på nytt.
Men, programmene må ha et sted å være mens de venter på en semafor. "Du er nummer tre i køen," sier stemmen fra drosjesentralen når du bestiller drosje over telefonen. Vi har ingen problemer med å skjønne at vi kan være del av en logisk kø som vi ikke kan se i den fysiske virkeligheten, og likevel vente på en fysisk hendelse. Er vi tålmodige kommer drosjen snart. Drosjene er delte ressurser. Slik er det med programmene som kjøres under kontroll av operativsystemet. De står i køer og venter på semaforene. Når semaforen blir ledig, vil den som har ventet lengst bli "vekket opp", og dermed få beskjed om at nå er det er din tur; gjør hva du vil med den ressursen som semaforen passer på, men husk å frigi semaforen når du er ferdig.
Når et dataprogram venter i en kø, kan det spesifisere om det ønsker å vente til ressursen blir ledig, eller til en spesifisert tid har gått ut. Operativsystemet håndterer tidsdeling slik at et ivrig program kan bli avbrutt og plassert bakerst i køen slik at også de andre programmene kan få komme til. Dermed kan et ventende program også få kjøretid og vekkes opp både om printeren ikke blir, eller blir ledig.
Om programmene har feil i oppskriften eller algoritmen for hvordan printersemaforen skal benyttes, kan ventende program aldri bli tildelt printeren. Jeg har oppfattet høyreregelen i trafikken slik: Vi skal stoppe for alle som kommer fra høyre. En så enkel oppskrift kunne, om den ble fulgt bokstavelig i et dataprogram, føre til vranglås. Hva om det kommer en bil inn i et veikryss fra hver side, fire biler i alt? Hvem skal stoppe for hvem? Alle sjåførene vil samtidig oppdage at de har en bil til høyre for seg, følge regelen, og stoppe. Ingen har rett til å kjøre videre.
Når programmer i en datamaskin er utsatt for vranglås, vil maskinen gradvis kunne "fryse til". At fire biler står i et kryss og ikke kommer videre, er ikke noe problem for andre enn de fire, før det kommer flere som skal benytte seg av den delte ressursen som et gatekryss er. Når en oppskrift som oppfattes som enkel ikke kan benyttes, forklarer det noe av hvorfor det er så vanskelig å få datasystemer til å fungere prikkfritt. Her lurer farer på alle kanter, og det stakkars operativsystemet skal også prøve å oppdage flest mulig feiltilstander. Men man kan velge å løse problemene på andre måter. Sett inn lysregulering i kryssene! Dette fjerner bruken av vikeregelen fra høyre. Da er det operativsystemet som styrer lysreguleringen.
I dataverdenen er man opptatt av å heve abstraksjonsnivået. Det betyr at en bruker eller en programmerer ikke trenger å vite hvordan intern organisering er gjort. Om jeg skal sende et brev fra Trondheim til Oxford skriver jeg ikke "til Oxford via Oslo og London" utenpå brevet. For om postverket den dagen sendte via Bergen, som jeg ikke hadde spesifisert, skulle de i så fall kaste brevet bare fordi de ikke kunne følge min spesifikasjon? Postverket er min tjener og det spiller ingen rolle hvordan brevet kommer fram, bare det når målet. Slik er det også med gode dataprogrammer; det skal ikke være nødvendig å vite hvordan noe gjøres, bare hva man har lov til å skrive på konvolutten. Dette kalles innkapsling. Programmeringsspråket og operativsystemet i fellesskap tilbyr mekanismer slik at programmereren og brukeren kan gjøre det rett. Og ble det ikke helt rett likevel, kan operativsystemet og prosessoren oppdage grove feil og varsle oss som brukere. Men da blir vi irritert, for vi kan miste det vi har arbeidet med i flere timer – og hvem andre enn programvareprodusentene kan levere halvfabrikata som ferdigvare, til full pris? Men, årsaken trenger altså ikke være enkel. Jo mer "vanskelig" man løser et komplekst problem, desto verre blir det. Kunsten er å finne enkle løsninger – ved å roe seg ned til man oppdager at olje og vann faktisk skiller seg av seg selv, og ikke prøve å separere dem mens alt er én saus.
Vi kan for eksempel la være å tenke på semaforer ved å innføre et nytt og enklere regelsett. Vi snakker om brev eller meldingstrafikk mellom programmer. I stedet for å la programmene bruke en ressurs direkte, sender et dataprogram en melding til et annet program som bare styrer denne ene ressursen. Når meldingen blir levert fra produsenten, kopieres den og sendes til det ventende programmet. Originalen kan så leveres tilbake til produsentprogrammet når det får kjøre igjen, slik at det kan benytte "papiret", eller dataområdet, om igjen. Systemer basert på denne teknikken kalles meldingsbaserte. Brukerprogrammene trenger ikke semaforer mer, og derfor forsvinner de assosierte synkroniseringsproblemene også. I vårt eksempel med printing er programvaren konstruert slik at ett program eier printeren hele tiden. Så får man heller sende meldinger til dette programmet når printeren er ønsket. Man kan si at printeren har fått fast bosted; den flytter ikke fra program til program.
La oss se på hvordan meldinger håndteres dersom signalveien kortvarig forstyrres eller mottakeren overøses med meldinger. Om vi ser på brannvarslingssystemet igjen, ville det i utgangspunktet være uakseptabelt å konstruere det slik at man kan tillate å miste en melding. Økende røykmengde og forvarsel fra rom 101, eller enda mer alvorlig: fullt brannvarsel fra rom 102 er kritiske meldinger som må fram for enhver pris. Men hvis begge varslene er forårsaket av samme brannkilden, holder det kanskje med det første? Som regel aksepteres det at man kan miste alarmmeldinger fra et naborom når en alarm først har gått. Og kanskje er det også akseptabelt å kaste forvarselmeldinger dersom det er nok alarmmeldinger å håndtere? Kanskje bør meldinger prioriteres? Men det kommer an på. I såkalte sikkerhetskritiske systemer, som brannvarslingssystemer ved atomkraftverk, kreves det at alle sendte meldinger mottas og loggføres. Meldingspostverket må ha god orden i rutinene.
I en datamaskin er det derimot opplagt at enkelte meldinger må kastes. Om du på PC'en trykker ned en musetast når den blinkende pekeren er utenfor et programvindu, kan det hende at operativsystemet ikke finner noe program som vil ha musetrykket. Da blir klikket rett og slett kastet. Det samme vil skje om det påtrykkes flere meldinger utenfra, for eksempel fra internett, enn det maskinen rekker å håndtere. Måten meldingene sendes og mottas på er slik at det vil bli oppdaget om meldinger kastes, mistes eller forstyrres, og de kan bli forsøkt sendt om igjen om man oppdager problemer.
Det er ikke bare meldinger som kan gis prioritet. Hvordan et gitt dataprogram skal kjøres i forhold til de andre programmene, kan styres ved å tilordne gjensidig prioritet mellom dem. Hvordan slik prioritet skal settes, og ikke minst, eventuelt forandres underveis av operativsystemet, er et eget problem- og feilområde som vi ikke skal gå nærmere inn på her.
Operativsystemet Windows håndterer altså blant annet semaforer,
meldinger
og køer, og passer på at oppgavene blir noenlunde rett fordelt. Et
annet operativsystem
som er blitt populært, i alle fall hjemme hos datafolk, er Linux. Linux
har den fordelen
at det ikke krever så mye av maskinen som Windows gjør, og det er helt
gratis. Du kan
laste det ned fra internett, og gjøre maskinen din ganske forandret
etterpå. Du kan
også installere det slik at du kan velge mellom Linux eller Windows ved
oppstart.
"Linux"-betegnelsen er en kombinasjon av navnet til finnen som har vært
hovedmannen bak systemet, Linus Torvalds – og Unix, et annet
operativsystem, som
Linux er ganske likt.
På historiens rikholdige søppelplass ligger også et norsk operativsystem, Sintran, som ble benyttet i Norsk Data sine maskiner. Engelskmannen Tim Berners-Lee benyttet dette systemet da han på den europeiske forskningsinstitusjonen CERN i 1980 bygde opp det som senere skulle vise seg å bli den spede begynnelsen til internett slik vi kjenner det i dag, med nettleserbasert teknologi. Nå, tjue år etter, er de tre viktigste nettleserne på verdensmarkedet Microsofts Internet Explorer, Netscapes Navigator og den norske nettleseren Opera.
La oss se på en viktig komponent i mange operativsystemer: klippetavla. Dette er et avansert såkalt meldingsbuffer som du kan benytte mellom forskjellige programmer. Det koster penger å være påkoblet internett, og du har kanskje lurt på om det finnes noen mulighet for å skrive e-post uten at tellerskrittene går? Det er flere muligheter. Du kan skrive et dokument frakoblet, og så sende det etter at du har logget deg på, som et vedlegg til e-posten. Men for rene tekstmeldinger kan du også benytte klippetavla. Mens du er frakoblet internett tar du opp en enkel tekstbehandler som for eksempel "Notisblokk" og skriver brevet, og du kan ta deg god tid; ingen tellerskritt løper. Så markerer du all teksten i dokumentet og legger det inn i klippetavla. Der ligger teksten din helt til den blir overskrevet av noe annet. Deretter logger du deg på internett, tar opp e-postleseren din, og limer brevet som ligger i klippetavla inn på den skjermsiden du får opp i det du sier du skal sende noe. Der fyker teksten inn, du kan trykke på "send" og logge deg av.
Dersom du bruker klippetavla en del, vil du oppdage at du kan bruke den til alt du kan markere, i de fleste program. Men prøv å kopiere et bilde inn i klippetavla og deretter lime det inn i Notisblokk! "Lim inn"-muligheten er fjernet fordi operativsystemet vet hva som ligger i klippetavla, og Notisblokk vet hva den selv kan akseptere – bare ren tekst. Klippetavla lagrer ikke bare innhold, men også hva innholdet er satt sammen av, én av ingrediensene i begrepet protokoll. Protokollene tekst, bilde og både tekst og bilde, er eksempler. Den andre ingrediensen er beskrivelse av flytmekanismen mellom programmene, slik at man ikke skal snakke i munnen på hverandre. Derfor må protokollene på sender- og mottakersidene være like; de må passe sammen som støpsel og stikkontakt, ellers får vi ingen flyt, som i Notisblokk-eksempelet.
Enkelte ganger har jeg opplevd at jeg blir kastet ut av en telefonkø. Dette synes jeg ofte er dårlig gjort, om jeg har ventet lenge. Et operativsystem kan også stoppe et program når det må, men da kan sakene begynne å bli vanskelig for andre programmer. Hva om programmet som stoppes eide en semafor som et annet program ventet på? Hvordan et operativsystem håndterer slike og mange andre situasjoner, avgjør til slutt hvor sikkert systemet er. Og dette igjen avgjør hvor mye vi kan stole på den enheten systemet styrer.
Når en programmerer skriver et dataprogram, har han en skriftlig oversikt å gå etter. Hvordan kan han benytte akkurat dette operativsystemet, og hvilke programvare-bibliotekstjenester tilbys? Målet er å gjenbruke de programmene som operativsystemet og tredjepartsleverandører tilbyr. Eksempler her er kommunikasjons-"drivere" for internett, slik at hver enkelt programmerer slipper å sette seg inn i alle protokollene som benyttes – drivere for skjerm, mus og tastatur, og filsystemer som passer på at filene du lagrer unna kan finnes igjen neste gang du trenger dem.
Dette er vel og bra, men det gir ikke nødvendigvis portabilitet, slik at programmene også kan kjøres på andre operativsystemer. Ofte er god portabilitet et mål i seg selv. Brukeren slipper da å kjøpe to versjoner av programvaren, og programmereren slipper å lage to versjoner. Verktøyet som programmereren benytter for å få dette til, fungerer omtrent som i en bok der vi ønsker å skrive om enkelte setninger, det vil si forandre programmet. Vi må bare garantere at ingen av overskriftene forandres. Programmer skrevet i programmeringsspråket Java skal kunne kjøre uforandret på flere operativsystem. Dette ordnet det amerikanske selskapet Sun (som konstruerte språket) ved å legge et bibliotekslag med faste overskrifter over operativsystemet. Reklame-"snuttene" som vises i nettleseren din når du er på internett kan være eksempel på slike program. De virker like godt både på Windows, Linux og Apples operativsystem Mac OS.
Når du leser annonser for PC'er, har du kanskje fundert på hvorfor det ikke er avgjørende hvilken PC-fabrikant og hvilken modell du velger. Dette er takket være et lag med faste programoverskrifter som ligger rett over elektronikken i PC'ene. Dette laget kalles BIOS, og utgjør et lite operativsystem som ene og alene har til oppgave å gjøre selve konstruksjonen av maskinen usynlig for programmene. Det som er inni denne BIOS'en varierer fra maskin til maskin, mens overskriftene alltid er like. Og vi kan shoppe og bare spørre om motor og lakk, mens rattet og pedalene alltid ser like ut.
Kan vi nå gjenfortelle hva et operativsystem er? Jo, det er det dataprogrammet som starter før alle de andre programmene, og som kjører hele tiden. Dette programmet sørger for at de andre programmene, når du starter dem opp eller krever respons fra dem, får sin rettferdige del av maskinens kjøretid – ikke for mye, ikke for lite. Og operativsystemet passer på at det ikke blir konflikter mellom flere programmer du ønsker tjenester fra, og prøver å løse eventuelle problemer som måtte oppstå. Operativsystemet tilbyr også en del fellestjenester, slik at flere programmer kan gjenbruke disse ferdige funksjonene.
Jeg avslutter med en anekdote om en spesiell side ved programmeringsspråket Java. Vi har sett at en sentral faktor ved semaforer er at man kan være del av en kø og passivt vente på at semaforen skal bli ledig. Sun la et liknende konsept inn i Java. Dette konseptet var utviklet av dansken Per Brinch Hansen, som er ansatt ved Syracuse-universitetet i Canada, og engelskmannen C.A.R. Hoare, tidlig på syttitallet. Men da Brinch Hansen oppdaget at designerne av Java hadde gjort det slik at – joda, man kunne sove i en kø, men man kunne oppleve å bli vekket opp feilaktig, og så være nødt til å legge seg ned igjen – ble han harm [2]. Det er som å få en feiloppringing midt på natta; vi kan tåle det én gang, men ikke hele natta. Denne siden ved programmeringsspråket Java kan stå som eksempel på en løsning som ikke er skalérbar, med den betydning at det er greit for mindre system men økende vanskelig for større systemer. Og om konseptene ikke skalerer godt, kan det bli vanskelig å konstruere systemer som fungerer problemfritt i flere sammenhenger.
Så, heller ikke i dataverdenen går alle framskritt framover, selv om prosessorene i datamaskinene går fortere og fortere fra år til år – nå går de i gigahertz. Systemene våre skal hjelpe oss med å skrive brev, varsle brann, styre fly, og gi oss mulighet til å ringe etter hjelp – fra det trivielle til det kritiske. Det er svært viktig at operativsystemene som styrer de innretningene vi benytter oss av fungerer når de skal. Og, jo mindre vi merker til dem, desto bedre.
| © Øyvind Teig / NRK Fakta, 2002 |
P2-Akademiet - NRK P2s
populærvitenskapelige foredragsserie. (28.6.2001) |
| Referert fra Wikipedia: http://no.wikipedia.org/wiki/Operativsystemer (feb. 2009) | |
Operativsystemet - Dataprogram - Samtidige dataprogram - Delte ressurser - Semaforer som nøkler til delte ressurser - Det er lett å miste stafettpinnen i vekslingen - Ventekøer - Vranglås - Innkapsling og abstraksjonsnivå - Brev i stedet for nøkler - Prioritet: når kan brev kastes? - Andre operativsystem - Klippetavla - Protokoller - Sikkerhet - Programbibliotek - På et nivå er alle PC’er like - Sammendrag - Feiloppringing midt på natta
- [1]
- Jeg kjenner ikke til noen generell lærebok i operativsystemer på norsk. Om noen vet om en, send meg en epost! Et søk på http://www.gnist.no på "Operativsystem" gir to tilslag med dårlig bokpresentasjon. http://bokkilden.no/ gir ingen tilslag. http://www.universitetsforlaget.no/ heller ingen.
Men om du søker på "Operating system" vil du finne mye. Min favoritt er "Applied operating system concepts", Silberschatz, Galvin, Gagne. Wiley (2002). ISBN 0-471-36508-4- [2]
- "Java's Insecure Parallelism", Per Brinch Hansen, ACM SIGPLAN Notices 34, 4 (April 1999), pp38-45. Se Teig, kronikken "Trygt med Java?", Teknisk Ukeblad, 146 Årgang, nr. 32, 2. september 1999, side 54. Se http://home.no.net/oyvteig/pub/pub_abstracts.html#TrygtMedJava - eller les den direkte på http://www2.tekblad.no/arkiv/artikler/1999/32/s54/s54.html