Gedistribueerd programmeren

Maat: px
Weergave met pagina beginnen:

Download "Gedistribueerd programmeren"

Transcriptie

1 Gedistribueerd programmeren

2

3 Gedistribueerd programmeren Collegedictaat, september 2007 Gerard Tel Instituut voor Informatica en Informatiekunde Universiteit Utrecht

4 Opmaak: Gerard Tel, Utrecht c Copyright Gerard Tel / Universiteit Utrecht.

5 Voorwoord Dit is het dictaat van het vak Gedistribueerd Programmeren zoals dat gegeven wordt in september en oktober 2007 aan de Universiteit Utrecht. Het vak werd in 1999 voor het eerst gegeven en naar aanleiding van opmerkingen van gebruikers is het dictaat in de volgende jaren verbeterd. Het dictaat uit september 2003, 2004 of 2005 kan in 2006 en 2007 worden gebruikt, maar hoofdstuk 6 hieruit is vervallen en in 2007 is de beschouwing over randomisering bij wachtvrije consensus toegevoegd. Deel I, de hoofdstukken 1 tot en met 4, behandelt klassieke synchronisatiemethoden voor multi-threaded programma s die communiceren via variabelen onder read-write atomicity. Deel II, de hoofdstukken 5 tot en met 8, behandelt message passing algoritmen. Deel III, de hoofdstukken 9 tot en met 11, behandelt moderne wachtvrije synchronisatietechnieken. Natuurlijk zijn er over deze onderwerpen ook boeken. Het eerste deel put vooral uit Burns en Davies [BD93], het tweede deel uit Tel [Tel00], en het derde uit Attiya en Welch [AW98]. Een uitgebreidere literatuurlijst is achterin opgenomen. Ik verzoek de lezer, de programmafragmenten met enige welwillendheid te lezen. Er is geprobeerd de syntax van Java in enige mate na te volgen, maar het volgen van een daadwerkelijk bestaande syntax is ondergeschikt aan de begrijpelijkheid van de uitgedrukte algoritmen. Wij hopen studenten en andere lezers met dit boekje aangename, en vooral leerzame uren te bezorgen. De opgaven in dit dictaat zijn een voorbeeld van hoe tentamenvragen er uit kunnen zien. Sommigen stimuleren de student tot het nader bestuderen van een onderwerp, anderen vereisen een behoorlijk diep inzicht in de stof. Er zijn er een paar bij, waarop ik zelf (nog) geen pasklaar antwoord heb: 1.9, 2.2, 3.1, 3.14 met semaforen, 4.6, 5.17, 8.12, 8.15, Ideeën zijn welkom! Omdat er ook veel tentamenvragen letterlijk zijn overgenomen, zit er soms tussen de verschillende vragen overlap, en komen vragen zelfs dubbel voor. Tentamenvragen zijn niet altijd eenduidig in een hoofdstuk te plaatsen; soms is voor de beantwoording ook kennis van een eerder of later hoofdstuk nodig. Ik dank Annet Roodenburg voor het maken van de illustraties in kaders 3.4 en 5.2. Gerard Tel, Utrecht, zomer v

6 Inhoudsopgave Voorwoord Inhoudsopgave v vi 1 Inleiding: Concurrency Concurrency Waarom concurrency bestuderen? Processen, communicatie en taal Atomiciteit Scheduling Granularity Nogmaals scheduling Synchroniteit Fairness Opgaven bij hoofdstuk Mutual exclusion Probleemstelling Vier eenvoudige algoritmen Eerste poging: bezetvlaggen Tweede poging: de safe sluice De safe sluice met na-u Een Salomonsoordeel: om de beurt Dekkers algoritme Lamports bakery-algoritme Samenvatting en conclusies Opgaven bij hoofdstuk Synchronisatieprimitieven Semaforen voor programmeurs Binaire en algemene semaforen Mutual exclusion met semaforen Semaforen voor systeembouwers Toepassing in de begrensde buffer Monitors Begrensde buffer met monitors Samenvatting en conclusies Opgaven bij hoofdstuk vi

7 Gedistribueerd programmeren vii 4 Dining Philosophers Een eenvoudige doch voedzame maaltijd Probleemomschrijving Eisen aan de oplossing Toepassingen Maaltijd met hindernissen Geen synchronisatie: vorkenconflict Synchronisatie per vork Globale synchronisatie Globale synchronisatie met token Veel eten en toch hongerige gasten Progress en no starvation Deadlock Wait-for-graphs Priority scheduling Deadlock detection and recovery Deadlock avoidance: servetten Deadlock prevention: ordening van resources Samenvatting en conclusies Opgaven bij hoofdstuk Electie Berichtuitwisseling Probleemstelling: electie Maak 0 de leider Wie is kleiner dan zijn voorganger Circuleer een token Enkele oplossingen Het algoritme van LeLann Het algoritme van Chang en Roberts Het algoritme van Peterson Een bewijs van ondergrens Samenvatting en conclusies Opgaven bij hoofdstuk Fouttolerantie en consensus Fouttolerant programmeren Foutmodellen Beslisproblemen Voorbeeld: flexibele electie Consensus-algoritmen Een triviale oplossing De replicated server De zwakke broadcast De sterke broadcast Onmogelijkheid van consensus Eisen op een consensus-oplossing Modelvorming Bivalentie in runs

8 viii Inhoudsopgave Bewijs en discussie Samenvatting en conclusies Opgaven bij hoofdstuk Randomisering Anonieme electie Het probleem en deterministische onmogelijkheid Een terminerende oplossing: Monte Carlo Een probabilistisch terminerende oplossing: Las Vegas Terminerend met faalkans Coordinatie over een broadcast-kanaal Probleemstelling Niet-randomiserende oplossingen Een randomiserende oplossing: de vervalprocedure Ben-Ors consensus-algoritme Uitleg van het algoritme Bewijs van overeenstemming en geldigheid Bewijs van convergentie Samenvatting en conclusies Opgaven bij hoofdstuk Foutdetectie Motivatie: synchrone consensus Definities Implementaties van foutdetectors Synchrone systemen: perfecte detectie Partiëel synchrone systemen: uiteindelijk perfecte detectie Ondersteuning door het besturingssysteem: incompleet Consensus met zwakke accuratesse Uiteindelijke zwakke accuratesse Samenvatting en conclusies Opgaven bij hoofdstuk Wachtvrije implementaties met registers Voordelen van wachtvrije synchronisatie Probleemstellingen modelleren als objecten Definities van gebruikte objecten Implementaties Registers: van single naar multiple reader Hoe het niet moet Oplossing: readers helpen elkaar Het snapshotobject Samenvatting en conclusies Opgaven bij hoofdstuk Wachtvrije consensus Consensusobject met registers Consensus met test-and-set, queue en compare-and-swap Consensus met test-and-set Queue implementeert 2-consensus

9 Gedistribueerd programmeren ix Queue implementeert geen 3-consensus Het consensusgetal Consensusobject met compare-and-swap Wachtvrije hiërarchieën Consensus met randomisering Samenvatting en conclusies Opgaven bij hoofdstuk Universaliteit van consensus Compare-and-swap implementeert test-and-set Fetch-and-increment Compare-and-swap implementeert fetch-and-increment Test-and-set implementeert fetch-and-increment Universaliteit Consensus is universeel Werking van de universele implementatie Bewijs van de universele implementatie Reflectie Universaliteit van naamgeving Samenvatting en conclusies Opgaven bij hoofdstuk Bibliografie 167 Index 169

10 x Inhoudsopgave

11 Hoofdstuk 1 Inleiding: Concurrency Het doel van dit hoofdstuk is een eerste overzicht te geven van een aantal begrippen die in gedistribueerd (of concurrent) programmeren van belang zijn. Aan de orde komen onder andere: concurrency, non-determinisme en randomisering, atomiciteit, scheduling en berekeningsbomen, granularity en fairness. 1.1 Concurrency De term concurrency is, hoewel het woord letterlijk gelijktijdigheid betekent, niet strikt gereserveerd voor situaties waar meerdere dingen tegelijk gebeuren. We spreken al van concurrency wanneer in een programma de onderlinge volgorde van deelberekeningen niet is aangegeven. Een sequentieel programma daarentegen bevat instructies en geeft ook aan in welke volgorde ze uitgevoerd worden. Een voorbeeld is programma 1.1, een fragment dat een binomiaalcoëfficiënt int binco (int n, int k) { int uitkomst if (k==0 or k==n) { uitkomst = 1 } else { int links, rechts links = binco(n-1,k) rechts = binco(n-1,k-1) uitkomst = links+rechts } return uitkomst } Programma 1.1: Berekenen van binomiaalcoefficienten. 1

12 2 1 Inleiding: Concurrency int binco (int n, int k) { int uitkomst if (k==0 or k==n) { uitkomst = 1 } else { int links, rechts cobegin { links = binco(n-1,k) } { rechts = binco(n-1,k-1) } coend uitkomst = links+rechts } return uitkomst } Programma 1.2: Berekenen van binomiaalcoefficienten. uitrekent op basis van de bekende formule ( n k ) 1 ( ) ( ) als k = 0 of k = n = n 1 n 1 + als 0 < k < n k k 1 ( ) n De binomiaalcoëfficiënt geeft het aantal verschillende deelverzamelingen met k elementen van een verzameling met n elementen. Programma 1.1 rekent deze formule precies uit; van k belang is hier het else-deel. Conform de formule wordt gespecificeerd dat er een linker en een rechterstuk moet worden berekend en dat die moeten worden opgeteld. Maar het programma zegt ook, dat eerst links en dan pas rechts wordt uitgerekend, in de tijd dus zo: Links Rechts Andersom had natuurlijk ook gemogen, de twee statements worden dan gewoon omgedraaid en de executie wordt zo: Rechts Links Maar waarom zouden we eigenlijk een volgorde specificeren? In programma 1.2 is het else-gedeelte vervangen door een concurrent gedeelte. cobegin en coend constructie, als in Met de cobegin { links = binco(n-1,k) } { rechts = binco(n-1,k-1) } coend

13 1.1 Concurrency 3 i = 5 ; cobegin { i = 6 } // I { j = i } // J coend return j Programma 1.3: Twee concurrente toekenningen. wordt aangegeven dat links en rechts in willekeurige volgorde of zelfs overlappend kunnen worden berekend. Dan zijn de beide genoemde executies mogelijk, maar ook zoiets als dit: Links Rechts of dit: Links Rechts waarbij de deelberekeningen elkaar overlappen. Je weet natuurlijk nooit, welk van de twee deelberekeningen langer duurt. Een programma of systeem waarbij de executievolgorde niet vast ligt noemen we een concurrent programma of systeem. De termen parallel en gedistribueerd worden ook gebruikt maar sommigen hechten er een iets andere betekenis aan Waarom concurrency bestuderen? Je kunt bij het programmeren concurrency gebruiken, bv zoals boven, maar er zitten een paar verschrikkelijke adders onder het gras. Dit heeft ermee te maken dat je als programmeur feitelijk een stuk controle over wat er gebeurt uit handen geeft. Terwijl je bij het eerste fragment weet wat er gaat gebeuren (de eerste executie), zijn er bij het tweede fragment meerdere mogelijkheden. In welke volgorde of mate van overlap de deelberekeningen worden uitgevoerd wordt niet langer door de programmeur bepaald. Er is sprake van non-determinisme en dit kan heel makkelijk leiden tot programma s die meerdere uitkomsten kunnen hebben. Bij programma 1.2 gebeurt dit niet omdat de twee deelberekeningen geheel onafhankelijk zijn, maar bekijk nu programma 1.3. De twee delen I en J die concurrent worden uitgevoerd refereren aan een gemeenschappelijke variabele i (die in J wordt gelezen en in I wordt geschreven). Een aantal personen compileert programma 1.3 op z n computer en draait het 20 keer, dit zijn de uitkomsten die ze vinden: Anneke Bob Carla Dick Erik Freek

14 4 1 Inleiding: Concurrency Kader 1.4: Multithreading in de Netscape-browser De Netscape-browser is een voorbeeld van een programma dat meerdere taken tegelijk kan verrichten. Je kunt bijvoorbeeld met je browser-window een groot bestand downloaden en ondertussen met het mailwindow je ophalen. Er kunnen een groot aantal windows tegelijk open zijn. Het programma kan ook crashen en stuurt dan tussen al het andere werk door een foutmelding naar de fabrikant. Bij het maken van zo n programma wordt veel gebruik gemaakt van concurrency. Meestal is er per window al een thread, en voor het downloaden van een bestand wordt weer een nieuwe thread opgestart. Door het opstarten van een nieuwe thread wordt bereikt dat, terwijl de taak wordt uitgevoerd, het window in staat blijft om nieuwe opdrachten (zoals het afbreken van de download) te verwerken. Het idee dat een programma (of programmafragment), met eventueel een gegeven invoer, één mogelijke uitkomst heeft is blijkbaar voor concurrente programma s niet geldig. Een specificatie van een programma is daarom nooit de vastlegging van één specifieke uitkomst die bij de gegeven invoer hoort, maar een karakterisering van het toegelaten gedrag. Concurrency introduceert een enorm lastig probleem, namelijk: hoe ervoor te zorgen dat het programma in alle mogelijke executies correct is. Als deze problematiek zo lastig is dat wij daar een heel college over moeten praten, waarom zouden we dan concurrency überhaupt toepassen? Concurrency wordt niet door bovengebruikte programma-constructies geïntroduceerd, maar bestaat gewoon. Immers, in een computer zijn altijd meerdere processen gelijktijdig actief, waarvan de instructies non-deterministisch door elkaar geklutst worden. De processen moeten resources delen, bv printers en filesysteem, en hierdoor ontstaan altijd de situaties waarin er tussen de verschillende delen interacties bestaan (als in Programma 1.3). Bezig zijn met concurrency scherpt het denken over programmeren. Bij denken over concurrency is het altijd nodig te denken in termen van specificaties van objecten, en te abstraheren van bepaalde implementaties. Bovendien, tegenover de genoemde nadelen staan ook grote voordelen van het daadwerkelijk toepassen van concurrency in programmatuur. Van moderne, muisgestuurde programmatuur verwacht je dat er commando s kunnen worden gegeven terwijl het vorige nog wordt verwerkt; zie kader 1.4. Dit gedrag vereist concurrency tussen het uitvoeren van verschillende taken.

15 1.2 Atomiciteit 5 Concurrency vereist minder programmeerwerk. Over alles wat je in een programma vastlegt moet je nadenken. Leg je geen volgorde vast, dan hoef je ook over de volgorde niet na te denken. Non-determinisme (dus ook concurrency) is flexibel. Door in een fase van het ontwerpproces keuzes open te laten, kun je in een latere fase, of bij onderhoud aan de programmatuur, nog mogelijkheden ter verbetering open houden. Concurrency geeft vrijheid aan de compiler. Door verschillende volgorden toe te staan kun je een slimme compiler die volgorde laten kiezen die hij het efficiëntst kan laten uitvoeren. Concurrency is efficiënt op een uniprocessor. Stel dat de computer begint met het uitrekenen van een zekere deelberekening maar even moet wachten, bv op disk-io. Concurrency staat dan toe dat de wachttijd wordt gevuld met het rekenen aan een andere deelberekening. Vrijheid van volgorde staat ook interleaving toe, dat wil zeggen, dat er afwisselend instructies van de verschillende threads worden uitgevoerd. Concurrency is efficiënt op een multiprocessor. Er wordt gesproken van parallellisme wanneer de diverse instructies daadwerkelijk tegelijkertijd worden uitgevoerd, met als doel de verwerkingssnelheid te verhogen; zie kader Grote instellingen als het KNMI gebruiken supercomputers met 32-voudig (of soms meer) paralellisme om de verwachting voor volgende week nog deze week af te krijgen Processen, communicatie en taal Onder een proces wordt bij programmeren meestal verstaan: een stuk code dat wordt uitgevoerd met een eigen namespace. Als je binnen dat proces concurrency gebruikt (zoals boven) en de verschillende delen hebben toegang tot dezelfde variabelen (objecten) dan spreekt men doorgaans van threads. Maar op andere momenten is in een systeem sprake van verschillende processen die toch met elkaar communiceren door gemeenschappelijke variabelen of objecten te lezen en te schrijven. Omdat bij interactie tussen processen dezelfde problemen optreden als bij de interactie tussen threads, zullen we het verschil tussen processen en threads niet zo nauw nemen. Naast gedeelde variabelen is er nog een andere veelvoorkomende manier van communicatie tussen processen: messages. Processen hebben dan sockets waar ze informatie in kunnen schrijven (zenden) of uit lezen (ontvangen). Een socket garandeert dat elke waarde die erin wordt geschreven ook exact eenmaal kan worden gelezen. Deze vorm van communicatie staat centraal in de hoofdstukken 5 tot 8 van dit boek. 1.2 Atomiciteit Bij concurrency mogen instructies in verschillende volgorden worden uitgevoerd of zelfs overlappen. Wat is het resultaat van overlappende instructies? We voeren deze discussie even aan de hand van programma 1.3 en programma 1.5 dat twee concurrente secties bevat. De threads werken onafhankelijk, maar we willen in de gedeelde variabele c tellen hoe vaak een bepaalde procedure wordt aangeroepen. In de wereld van sequentiële programma s betekent c=c+1 natuurlijk hetzelfde als c++. Laten we zeggen dat de linkerthread dit driemaal en de

16 6 1 Inleiding: Concurrency c = 0 cobegin {... { c = c c = c+1... c = c+1 c = c+1... c = c+1 c = c c = c+1 } } coend Programma 1.5: Overlappende updates. rechter het viermaal doet. De executies van deze statement binnen één thread liggen in de tijd gezien natuurlijk na elkaar: Links c=c+1 Rechts Tussen de threads onderling is er sprake van een min of meer willekeurige overlap. Wat is na afloop de waarde van variabele c? Het antwoord (tenzij speciale maatregelen zijn genomen): we weten het niet! Het ons bekende gedrag van variabelen en objecten is namelijk hun sequentiële specificatie, dat wil zeggen dat deze objecten zich gedragen zoals we verwachten wanneer er slechts één operatie gelijktijdig actief is. Onder concurrency geldt de sequentiele specificatie niet, en we hebben dus geen specificatie van het gedrag van c in deze executie. En aangezien we geen specificatie hebben berust elk antwoord dat we geven op onze intuïtie cq. kennis van de werking van de operatie c = c+1. Zo n antwoord is daarom onacceptabel; bij het programmeren mogen alleen conclusies die kunnen worden afgeleid uit specificaties als geldig worden aangenomen. Om uit sequentiële specificaties van instructies of objecten iets te concluderen over concurrent gedrag gebruiken we een axioma en een definitie. Axioma 1.1 (Onafhankelijkheidsaxioma) Operaties die geen gemeenschappelijke variabelen gebruiken beïnvloeden elkaar niet. Dwz., de concurrente uitvoering van a=7 en b=c geeft hetzelfde resultaat als a=7 ; b=c of b=c ; a=7 (mits er hier geen aliassen in het spel zijn). De correctheid van programma 1.1 kan worden beredeneerd met dit axioma. (Natuurlijk moet wel grondig worden gecontroleerd dat er niet ergens verstopt in een subroutine toch gemeenschappelijke variabelen worden gebruikt!) De situatie dat concurrente programma s geen variabelen gemeen hebben is blijkens dit axioma niet zo moeilijk te bestuderen. Inderdaad zijn in moderne computers de diverse programma s zo mooi van elkaar afgeschermd, dat je als programmeur geen last hebt van programma s die gelijktijdig met het jouwe draaien.

17 1.2 Atomiciteit 7 Kader 1.6: Atomiciteit in IBM System/360 en 370. In 1964 lanceerde IBM zijn nieuwe processorarchitectuur System/360 [GS87], die over een performance ratio van 1 op 20 bruikbaar moest zijn. Het Model 40, geïntroduceerd in april 1964 (foto), had een kloksnelheid van 1.6MHz en 256kB geheugen. Model 600E uit 1987, vrijwel geheel compatibel met Model 40, had twee CPU s met een kloksnelheid van 58MHz en 1024MB geheugen. De eerdere modellen hadden maar één processor; omdat er allen maar tussen twee instructies van thread geswitched kan worden, is het dan niet van belang je af te vragen wat er precies tijdens een instructie gebeurt. Een Test-and-Set instructie bestond uit twee geheugenoperaties die onlosmakelijk verbonden waren. Met de introductie van multi-processoren werd alles subtieler. De vroege machines deden een instruction retry wanneer er tijdens een instructie iets mis ging, maar een tweede processor kon hierbij (foute) tussentijdse waarden zien. Zie ook Kader 9.1. Nu zal er in de werkelijkheid vrijwel altijd in één of andere vorm sprake zijn van interactie, ook met andere programma s, bijvoorbeeld doordat resources (disk, modem) worden gedeeld. Dit gebruik is dan mooi afgeschermd via system-calls, maar er kan ook bewust interactie worden gecreëerd op een manier als in programma 1.3. Bij het redeneren over zulke programma s is het prettig te mogen redeneren alsof de instructies van de diverse threads in één of andere volgorde na elkaar worden uitgevoerd. De basis voor een dergelijke redeneerwijze ligt in de volgende definitie. Definitie 1.2 (Atomiciteit) Een operatie (of collectie operaties) is atomair als het resultaat van een aantal, mogelijk overlappende, uitvoeringen ervan altijd gelijk is aan het resultaat dat ontstaat wanneer deze operaties na elkaar worden uitgevoerd; elk in een ondeelbaar kort moment dat ligt tussen het begin en einde van de daadwerkelijke uitvoering. Merk allereerst op, dat atomiciteit een definitie betreft en geen impliciete aanname; per situatie moet worden bekeken of bepaalde operaties wel of niet atomair zijn. Verder is van belang op te merken, dat atomiciteit van operatie niet betekent dat de altijd na elkaar worden uitgevoerd, maar alleen dat het resultaat hetzelfde is als wanneer ze na elkaar worden uitgevoerd. De ontwerpers van de IBM System/360 architectuur (Kader 1.6) formuleerden al, dat het niet relevant is of situaties van elkaar verschillen, maar can you prove to me that any program could ever detect that difference [GS87]. Het tweede deel van de definitie beperkt de volgorde waarin de operaties denkbeeldig na elkaar mogen worden geplaatst, en voegt daarmee een eis aan de betekenis van atomiciteit toe. Ter illustratie toont figuur 1.7 een schrijfactie w (write x, 1) die de waarde 1 in variabele x schrijft, waarbij tijdens de uitvoering twee leesacties ra en rb op x worden gedaan. Dat

18 8 1 Inleiding: Concurrency tijd Waarde van x bij aanvang is 0. rb w read x: 1 write x, 1 ra read x: 0 Figuur 1.7: Overlappende lees- en schrijfacties. leesactie rb eerder begint en eerder eindigt dan schrijfactie w, maar toch de nieuwgeschreven waarde oplevert is niet strijdig met de aanname dat lezen en schrijven atomair zijn. De waarde 1 wordt immers opgeleverd door een leesactie die niet met de schrijfactie overlapt, maar er geheel na plaatsvindt. Evenmin is het strijdig met de atomiciteit dat leesactie ra met het schrijven overlapt en de oude waarde 0 oplevert. Deze oude waarde is immers correct voor een leesactie die in zijn geheel voor de schrijfactie plaatsvindt. De gecombineerde executie waarin beide leesacties voorkomen is echter wel strijdig met de atomiciteit en dit komt door de eis dat contractiepunten zijn aan te wijzen binnen het interval van daadwerkelijke uitvoering. De uitkomsten van alle acties zijn juist voor deze volgorde van uitvoering: ra, w, rb; het is dus mogelijk om bij figuur 1.7 een volgorde van de instructies te vinden waarvoor het resultaat juist is. Maar in deze volgorde komt ra voor rb en omdat het interval van daadwerkelijke uitvoering van rb in zijn geheel voor het interval van daadwerkelijke uitvoering van ra ligt, is het niet mogelijk om binnen deze intervallen contractiepunten te kiezen in deze volgorde. De executie van figuur 1.7 kan daarom bij atomaire lees- en schrijfoperaties niet voorkomen. Atomiciteit is een aaname die je over bepaalde instructies kunt maken of die je voor bepaalde instructies kunt implementeren. Kort gezegd, een executie van een atomaire instructie mag je je voorstellen als geconcentreerd op een punt binnen het tijdsinterval waarin hij wordt uitgevoerd. Neem weer de executie van programma 1.5 en neem aan dat de operatie c = c+1 als atomair mag worden beschouwd. (In code wordt dit soms aangegeven met punthaken: <c = c+1>). De atomiciteit zegt dat de collectie overlappende executies hetzelfde resultaat heeft als de uitvoering van 7 instructies c = c+1 na elkaar. Na afloop is de waarde van c dan 7. Realiseer je op dit punt echter, dat operaties bepaald niet vanzelf atomair zijn! Links c=c+1 Rechts Ook heeft de programmeur geen invloed op de onderlinge volgorde van de contractiepunten. Veronderstel, dat een operatie lees c wordt uitgevoerd, overlappend met de eerste twee operaties c=c+1. De uitkomst van de operatie kan 0, 1 of 2 zijn en dit kan per executie verschillen.

19 1.3 Scheduling 9 Begin I J J I Figuur 1.8: Executieboom van programma Scheduling Laten we nu aannemen dat ons programma is opgebouwd uit atomaire instructies; volgens de definitie is de executie (zelfs als de verschillende instructies elkaar daadwerkelijk overlappen) equivalent aan de uitvoering van de instructies in een of andere volgorde. Instructies die na elkaar in dezelfde thread zitten komen ook in die volgorde na elkaar, maar hoe zit het met de onderlinge volgorde van instructies uit verschillende threads? Beschouw weer even programma 1.3 en neem aan dat de twee instructies elk atomair zijn. Een compact overzicht van de mogelijke executies geeft de executieboom in figuur 1.8. Deze boom geeft voor elke mogelijke toestand van het systeem aan, welke stappen mogelijk zijn. In de beginsituatie is een instructie van hetzij thread I, danwel thread J mogelijk. Wordt de instructie van thread I uitgevoerd, dan is in de volgende situatie alleen de instructie van thread J nog maar mogelijk. Een executie van het programma komt nu overeen met een enkel pad vanaf de wortel in deze boom. Het non-determinisme komt tot uiting in het vertakken in de diverse knopen (in figuur 1.8 alleen in de beginknoop). De boom in figuur 1.8 is nog vrij eenvoudig van structuur omdat elk pad precies dezelfde instructies bevat, waarbij alleen de volgorde kan verschillen. Een eerste ding dat we ons gaan realiseren is dat weliswaar vanuit het standpunt van de programmeur verschillende executies mogelijk zijn, maar dat we geen enkel zicht hebben op welke mogelijkheid gekozen zal worden. Dit maakt het gevaarlijk af te gaan op testen van het programma. Verder, dat we zelfs geen zicht hebben op het mechanisme dat dit gaat bepalen. Dit maakt het gevaarlijk af te gaan op onze intuïtie betreffende de werking. Een paar voorbeelden. Anneke heeft een wat simpele compiler die de concurrency er vrijwel uitcompileert: de gegenereerde code begint altijd met de eerstgenoemde thread en maakt de tweede pas actief als de eerste klaar is of niet verder kan. Annekes programma geeft dus altijd 6 als antwoord. Ook bij andere concurrente programma s wordt altijd het eerstgenoemde deel zoveel mogelijk eerst uitgevoerd. Bobs compiler is slim: die bedenkt dat er een machineinstructie kan worden bespaard door het tweede statement eerst uit te voeren, en in dit geval wordt er code gegenereerd die juist altijd het tweede statement eerst uitvoert. Bobs programma geeft dus altijd 5 als antwoord. Andere concurrente programma s worden misschien zo gecompileerd dat het eerstgenoemde deel eerst wordt uitgevoerd. Carla s compiler is wat moderner en genereert non-deterministische machinecode. Op het

20 10 1 Inleiding: Concurrency Programma A: Programma B: i=0 i=0 while ( i == 0 ) while ( i == 0 ) { cobegin { i=0 } { i = floor( rnd() * 2) { i=1 } coend print i print i } } Programma 1.9: Non-determinisme versus randomness. moment dat de twee threads worden uitgevoerd, kijkt het OS welke thread het eerst uitgevoerd kan worden. Dit verschilt per executie! Een redelijk afwisselend patroon is het gevolg, totdat er (zonder dat Carla dit door heeft) een fax binnenkomt, waardoor thread 2 in het voordeel komt en dus veel vaker gekozen wordt. Dick heeft ook zo n compiler en hij krijgt geen fax. Bij hem is meestal thread 1 in het voordeel, maar na een paar executies wordt een deamon 1 actief die zijn disk opschoont. Tijdens die activiteit is het efficiënter om thread 2 eerst uit te voeren, en het OS doet dat. Non-determinisme is dus bepaald niet hetzelfde als randomness! Om het verschil wat verder op scherp te zetten: deze twee fragmentjes kunnen allebei i zowel op 1 als op 0 zetten. cobegin { i=0 } { i=1 } coend i = floor( rnd() * 2) In programma 1.9 worden deze stukjes herhaald tot er een keer 1 komt. Is er verschil tussen programma s A en B? De uitvoer is een rij nullen met een 1: Bij A Uitvoer Bij B Kans mogelijk 1 mogelijk 1/2 mogelijk 01 mogelijk 1/4... mogelijk mogelijk (lengte k) mogelijk 1/2 k... mogelijk mogelijk 0 Het blijkt (niet verassend) dat de programma s dezelfde verzameling van mogelijke executies hebben. Echter, door gebruik van randomizering in B kunnen we daar over de diverse executies een kansverdeling opstellen. Bij A is zo n kansverdeling op de verzameling executies niet mogelijk, er is slechts een platte verzameling executies. Wat betekent het dat een programma termineert? (Dan wel, een of andere andere eigenschap vertoont.) Het betekent, dat alle executies eindig zijn. Noch A, noch B heeft deze eigenschap, want beide hebben een oneindige executie. Maar kan die voorkomen? Bij A is het een executie als alle andere, er is tusssen de executies onderling geen verschil. Bij B hebben de eindige executies samen kans 1, en de oneindige heeft kans 0. Daarom zeggen we dat 1 Zie voor de herkomst van dit, hier correct gespelde, woord.

21 1.4 Granularity 11 programma B termineert met kans 1. Terminatie met kans 1 is een strikt zwakkere eigenschap dan terminatie, en wordt ook wel probabilistische terminatie of convergentie genoemd. Randomisering wordt verder bestudeerd in hoofdstuk Granularity Doorgaans is een operatie als c=c+1 niet in zijn geheel atomair, maar opgebouwd uit een aantal afzonderlijke machine-instructies bv zo: LOADA c INCRA STOREA c Ook ingewikkelder operaties, zoals het invoegen in een zoekboom of operaties op een andere datastructuur, zijn opgebouwd uit instructies. Instructie LOADA c leest de waarde van c uit het geheugen en stopt hem in een register A in de CPU, INCRA telt daar 1 bij op, en STOREA c kopieert de waarde van het register naar het geheugen. Als er sprake is van atomiciteit op het niveau van deze instructies dan kunnen die van twee threads bijvoorbeeld als volgt worden geïnterleaved: LOADA c INCRA STOREA c LOADA c INCRA STOREA c Let op: hoewel beide threads het gebruikte register A noemen, is er sprake van verschillende registers! De registers zijn een soort locale variabelen van de threads. Wat is de waarde van c na afloop (als hij bv eerst 0 was)? Door de overlap is er een update compleet verloren gegaan. Als in programma 1.3 de gehele instructie of LOAD en STORE operaties atomair zijn, is de uitkomst van het fragment altijd 5 of 6. Dit verklaart wat Anneke, Bob, Carla en Dick zien. Bij Freek is de situatie ook simpel: het gedrag van variabele i is niet gespecificeerd als lezen en schrijven overlappen, en Freeks computer heeft nog het fatsoenlijke gedrag om in geval van overlap altijd een 0 op te leveren. Maar wat is er bij Erik aan de hand? Hij heeft een binaire machine (de anderen misschien ook wel, maar we waren dit aspect nog niet tegen gekomen) die de waarden 5 en 6 bit voor bit atomair leest cq. schrijft. Als een gedeelte van de bits geschreven zijn en dan het lezen erdoor komt, kun je op sommige bitposities de oude en op andere de nieuwe waarde tegenkomen. Erik heeft in zijn machine wel atomiciteit, maar op een lager nivo dan lees/schrijfoperaties. Over het algemeen zijn processors zo ingericht dat machine-instructies atomaire eenheden zijn. Geheugens zijn doorgaans zo ingericht (door arbitrage bij de interface) dat afzonderlijke lees- en schrijfoperaties op registers atomair zijn. Daarom zullen we voorlopig steeds de aanname maken dat lees- en schrijf-acties atomair zijn. Dit heet read-write atomicity. Read-write atomicity geldt voor variabelen in Java, mits het een enkelvoudige variabele is die in ten hoogste 32 bits is opgeslagen. Een Java implementatie van programma 1.3 geeft dus als resultaat altijd 5 of 6. Omdat het verhogen van c twee read-write operaties vraagt, prefereren we meestal de schrijfwijze c=c+1 (waarin de dubbele toegang tot c in de notatie tot uiting komt) boven c++.

22 12 1 Inleiding: Concurrency Kader 1.10: Een cluster voor parallel rekenen Bij het ontwerpen van een parallelle computer is het van belang, vast rekening te houden met het soort taken waarvoor de machine wordt gebruikt. Dit cluster bestaat uit standaard PC s (zonder beeldscherm en toetsenbord), gekoppeld via een 100Mb Ethernet; per machine is een harde schijf geïnstalleerd. In deze opzet is relatief weinig communicatiecapaciteit beschikbaar, en relatief veel geheugen per processor. Het cluster kan daarom worden gebruikt voor taken, die in grote onafhankelijke rekenklussen zijn op te splitsen. Veel wetenschappelijke rekentaken vereisen steeds na enkele kleine stapjes het uitwisselen van data met andere delen van de berekening, en voor zo n klus is deze poor man s supercomputer niet geschikt. De laatste notatie is natuurlijk wel geschikt in omgevingen waar de ophoging als geheel atomair is. 1.5 Nogmaals scheduling We kijken nog even verder naar de mogelijke volgorden van atomaire instructies. Het mechanisme dat de volgorde bepaalt noemen we wel eens de scheduler. Verschillende schedulers die je in de praktijk kunt tegenkomen zijn: Interleaving: De threads worden op dezelfde CPU gedraaid maar ze mogen beurtelings een of meer instructies uitvoeren. Op een enkele CPU (uniprocessor) is echte overlap van machine-instructies niet mogelijk. Wel kan de controle van de CPU tussen willekeurig welke twee instructies van de ene naar de andere thread overgegeven worden. De aanleiding kan van alles zijn: interrupt door een ander proces in de machine de thread moet wachten (op IO) en wordt uitgeswapt een timer loopt af. Welke thread (of proces) daarna gekozen wordt hangt af van allerlei keuzen die in het Operating System zijn gemaakt, en dit is buiten zicht van de programmeur. Parallellisme: De verschillende threads worden op meerdere CPU s gelijktijdig uitgevoerd. Nu is er wel daadwerkelijke overlap van instructies mogelijk (maar atomiciteit garandeert natuurlijk dat dit voor het resultaat niet uitmaakt).

23 1.5 Nogmaals scheduling 13 i=0 ; j=0 cobegin { while (i==0) { i = 1 j++ } } coend Programma 1.11: Een mogelijk oneindige thread? We moeten de scheduler nooit zien als een identificeerbaar mechanisme, maar eerder als een samenspel van krachten en invloeden die bij uitvoering van concurrente code werkzaam zijn. Het verschil tussen interleaving en parallellisme werd significant toen de IBM System/360 (Kader 1.6) architectuur werd uitgebreid met multi-processor mogelijkheden. Je kunt namelijk vrij gemakkelijk een instructie implementeren die meerdere geheugen-accessen doet, zoals een ADD; het resultaat is atomair op een uniprocessor, omdat de thread niet tijdens de instructie onderbroken wordt. Het is echter heel moeilijk om deze ADD zo te implementeren dat hij ook op een multi-processor atomair is Synchroniteit Het is verleidelijk te denken dat threads wel ongeveer even snel zullen gaan. Bekijk cobegin { a1 ; a2 ; a3 ; a4 ; a5 ; a6 ; a7 ; a8 ; a9 ; a10 } { b1 ; b2 ; b3 ; b4 ; b5 ; b6 ; b7 ; b8 ; b9 ; b10 } coend In het meest extreme geval worden instructies ai en bi tegelijk uitgevoerd, maar op z n minst zou je zoiets verwachten als: a1 is wel klaar voordat b10 begint. In het algemeen maken we dergelijke aannamen niet! Er zijn manieren om twee sequences van 10 te mixen, en elk van die manieren is een mogelijke executie. Zelfs als je weet dat het programma op een twee-processor computer wordt uitgevoerd en dat beide processors even snel zijn: het is mogelijk dat op de beide processors je instructies worden ge-interleaved met instructies van andere programma s. Het is natuurlijk wel mogelijk extra aannamen over de scheduling te maken als de specificatie van je executie-omgeving dit rechtvaardigt. We spreken van een synchroon parallel systeem als gelijkloop tot instructieniveau is gegarandeerd. We spreken van partiële synchronisatie als er een getal k is waarvoor geldt dat er hoogstens k instructies van een thread kunnen zijn tussen twee opeenvolgende instructies van een andere thread. Nogmaals, in het algemeen maken we dergelijke aannamen niet Fairness Van eindige threads (dwz, met elk eindig veel instructies) bestaan maar eindig veel interleavings en die staan we alle toe. Maar hoe zit het als een thread oneindig veel instructies heeft, bv een eindeloze lus, of een potentieel oneindige? De linkerthread in programma 1.11 leest i en gaat daarmee net zo lang door tot de waarde 1 gezien wordt. De rechterthread doet niets anders dan i op 1 zetten. De executieboom van

24 14 1 Inleiding: Concurrency B T I T I A T A I. A T. A I. A T. A I T. A T I. A T I. A. A. A T I T T I T. A T. A I T. T. I T T I T Figuur 1.12: Een oneindige executieboom. dit programma is (deels) getekend in figuur 1.12 (de T, I, en A staan voor de Test, Increment en Assignatie in het programma). Elk pad in de boom bevat hoogstens één assignatie, daarna is namelijk de rechterthread klaar. Paden in de boom hebben verschillende lengtes doordat het aantal slagen van de lus in de linkerthread afhangt van de interactie. Termineert het programma en wat is de eindwaarde van j? Als eerste moet nu duidelijk zijn dat het programma in ieder gaval soms termineert (dwz, er bestaan eindige executies) en bovendien dat elk natuurlijk getal de eindwaarde van j kan zijn. Het is immers (voor willekeurig getal x) mogelijk dat er eerst x ronden van thread 1 worden afgewerkt en dat daarna thread 2 wordt gescheduled. Daarom is de executieboom in feite oneindig diep. Maar wat te denken van een executie waarin alleen maar instructies van thread 1 worden gedaan? Die kun je oneindig lang voortzetten zonder dat hij termineert. Ondertussen is de instructie van thread 2 dan wel al die tijd executeerbaar; het lijkt niet erg eerlijk om in een zo lange executie alleen thread 1 aan het woord te laten en thread 2 oneindig lang te negeren. Definitie 1.3 Een scheduler is fair als een instructie die continu executeerbaar is ook voorkomt. De genoemde oneindige executie is niet fair en wij nemen steeds aan dat de scheduler fair is. Programma 1.11 is dan een terminerend programma dat elk natuurlijk getal als uitvoer kan hebben. Hoewel de executieboom oneindig diep is, en dus een oneindig lang pad bevat, is dit pad niet als executie toegestaan onder een faire scheduler. Het bewijzen van terminatie met een fair scheduler is doorgaans lastiger dan wanneer de aanname van fairness niet wordt gemaakt. Een boek van Francez [Fra86] behandelt diverse vormen van fairness en de bijbehorende bewijsmethoden uitgebreid. Aanname van fairness sluit niet automatisch alle oneindige executies uit: slechts wordt uitgesloten dat gedurende een oneindig lange executie een bepaalde instructie consequent wordt

25 Opgaven bij hoofdstuk 1 15 overgeslagen bij de keuze. De aanname van fairness verandert niets aan het droeve noodlot van programma 1.9A. Immers, de oneindige executie sluit geen instructies af en is dus niet unfair. Opgaven bij hoofdstuk 1 Opgave 1.1 Hoeveel aanroepen van binco doet programma 1.1 om het ook sneller? ( n k ) te berekenen? Kan Opgave 1.2 Waarom ? Hoeveel interleavings zijn er als thread 1 k 1, en thread 2 k 2 instructies heeft? Als er drie threads zijn? Opgave 1.3 Hoe wordt concurrency uitgedrukt in C++, Java,...? (Vul op de stippels je favoriete programmeertaal in.) Hoe wordt concurrency op jouw computer uitgevoerd? Opgave 1.4 S1 en S2 zijn operaties met de eigenschap dat S1; S2 precies hetzelfde doet als S2; S1. Impliceert dit dat cobegin S1 S2 coend ook hetzelfde doet? Opgave 1.5 Operaties. (Uit het tentamen van februari 2001.) Van operaties S1 en S2 is gegeven dat S1 ; S2 hetzelfde effect heeft als S2 ; S1, dwz. bij sequentiële uitvoering is de volgorde niet van belang voor het resultaat. (a) Impliceert dit, dat ook cobegin S1, S2 coend hetzelfde effect heeft? Geef een bewijs of tegenvoorbeeld. (b) Wanneer zijn operaties atomair? (c) Neem nu als extra gegeven aan dat S1 en S2 atomair zijn en beantwoord vraag (a) opnieuw. Opgave 1.6 Definities. (Uit het tentamen van februari 2002.) (a) Wat is het verschil tussen een busy wait en een blocked wait? Van welk type zijn (1) de wait()-instructie, (2) de sleep(..)-instructie? (b) Wanneer is een executie unfair? (c) Wanneer zijn operaties atomair? Opgave 1.7 Basisbegrippen. (Uit het tentamen van mei 2002.) (a) Wat betekent fairness? (b) Leg het verschil uit tussen non-determinisme en randomness. (c) Wanneer is een collectie operaties atomair? Opgave 1.8 Basisbegrippen. (Uit het tentamen van mei 2000.) Om concurrent gedrag van programma s af te leiden uit sequentiëel gedrag van de gebruikte objecten gebruiken we het Onafhankelijkheids-axioma en Atomiciteit. Wat wordt onder deze begrippen verstaan? Opgave 1.9 Bekijk alle interleavings van cobegin { LOADA c ; INCRA ; STOREA c } { LOADA c ; ADDA 2 ; STOREA c } coend

26 16 1 Inleiding: Concurrency (ADDA 2 is een instructie die 2 bij register A optelt.) Veronderstel dat de afzonderlijke instructies atomair zijn. In hoeveel interleavings wordt c uiteindelijk met 0, met 1, met 2 en met 3 opgehoogd? Opgave 1.10 Scheduler. (Uit het tentamen van augustus 2000.) Wat is een scheduler? Kun je iets zeggen over de implementatie van schedulers? Wanneer is een scheduler fair? Opgave 1.11 Fairness. (Uit het tentamen van oktober 2006.) In dit programma kijkt thread 1 steeds naar variabele i, die door thread 2 afwisselend op 0 en 1 wordt gezet; initieel is i=0 en s=true: Thread 1: Thread 2: t = 0 while (i==0) while (s) { t=t+1 } { i=1-i } s=false print t (a) Beschrijf van dit programma een executie waarin thread 2 de waarde 2 print. (b) Beschrijf een oneindige executie die niet kan voorkomen als de scheduler fair is. (c) Beschrijf een oneindige executie die wel mogelijk is onder een fair scheduler. Opgave 1.12 Fairness. (Uit het tentamen van september 2004.) Dit programma (1.9A) heeft in een lusje twee concurrente statements, die i op 0, respectievelijk 1 zetten: i = 0 ; t = 0 ; while ( i==0 ) { cobegin { i=0 } { i=1 ; t = t+1 } coend ; print i ; } Er is read/write atomicity. (a) Laat zien dat er voor elke k N een executie is die een rij van k nullen en een één print. Wat is na afloop de waarde van t? (b) Geef de definitie van een fair scheduler. (c) Neem aan dat de scheduler fair is; is een oneindige executie van bovenstaand programma nu mogelijk? Leg uit! Opgave 1.13 Wat is na afloop van programma 1.5 de minimale, en wat de maximale waarde van c als het wordt uitgevoerd onder read-write atomicity? En als beide threads tienmaal c ophogen? Opgave 1.14 Experimenteer met programma Opgave 1.15 Geef bij elke toestand in figuur 1.8 en 1.12 de waarden van alle gebruikte variabelen aan.

27 Hoofdstuk 2 Mutual exclusion In dit en de volgende twee hoofdstukken kijken we naar een manier om niet-atomaire instructies in een concurrent programma te gebruiken. Het probleem om verschillende threads samen toegang te geven tot variabelen of andere resources in een systeem heet synchronisatie. In de volgende hoofdstukken wordt synchronisatie verkregen door binnen het tijdsinterval dat een thread met zekere actie bezig is, de daadwerkelijke toegang tot de gebruikte variabelen te concentreren in een kleiner interval. Het is hiervoor onder andere nodig, dat een thread wacht tot een andere thread met deze variabelen klaar is. Herinner, dat volgens de definitie operaties atomair zijn wanneer het resultaat van een aantal operaties, mogelijk geheel of deels overlappend, hetzelfde is als wanneer ze na elkaar worden uitgevoerd. Door te zorgen dat ze na elkaar worden uitgevoerd zal het resultaat hier inderdaad aan voldoen; we spreken dan van het sequentialiseren van operaties. Gedurende een periode van ongeveer 30 jaar (van 1960 tot 1990) was het sequentialiseren de enige manier om atomiciteit te verkrijgen, en het is nog steeds de meest gebruikte. Nog steeds wordt vaak gedacht dat atomiciteit impliceert (of per definitie equivalent is met) dat operaties ononderbroken worden uitgevoerd en dat andere threads noodzakelijk op het aflopen ervan moeten wachten. Sinds circa 1990 bestaan er echter alternatieve technieken om threads zonder wachten objecten te kunnen laten delen; deze worden vanaf hoofdstuk 9 besproken. 2.1 Probleemstelling Denk nog even terug aan de situatie waar verschillende threads updates doen op dezelfde variabele, dus zo: Thread 1 Thread 2 kritiek Figuur 2.1: Sequentialisatie van kritieke secties. 17

28 18 2 Mutual exclusion... cobegin Entry... CS... Exit Entry... CS... Exit Entry Entry CS CS Exit Exit coend Programma 2.2: Kritieke sectie, entry, exit.... c = c+1 c = c+1 c = c+1 c = c+1... Het systeem werkt correct als de operatie c = c+1 atomair is, maar dat is die niet: door interleaving van instructies is het resultaat van twee overlappende uitvoeringen ervan verschillend van twee uitvoeringen na elkaar. De oplossing die hiervoor al in de jaren vijftig werd bedacht is afgekeken van het kleinste kamertje van elk gebouw: een proces (of thread) dat aan de variable wil komen, sluit die als het ware voor anderen af. Anderen vinden de deur op slot, en hebben pas weer toegang als het bordje op VRIJ staat. Om de discussie algemener te maken volgen we de terminologie die hier gebruikelijk is en spreken van kritieke secties in het programma. Deze kritieke sectie mag willekeurige dingen doen met gedeelde variabelen, waar we verder niet op ingaan, we gaan ons concentreren op de vraag hoe je ervoor kunt zorgen dat er slechts één thread tegelijk mee bezig is. Het op slot zetten en vrijmaken van de kritieke sectie gebeurt in stukjes code die we het entry protocol en exit protocol noemen. De threads komen er dus uit te zien als programma 2.2; merk op, dat de Entry- en Exit-code expliciet in het programma wordt opgenomen op elke plaats waar het van gedeelde variabelen gebruik maakt. Een thread die ergens op de stippeltjes zit noemen we in de niet-kritieke sectie. In het programma dat de kritieke secties bevat wordt elk voorkomen ervan opgesierd met het entry- en exitprotocol. Vanuit het programma gezien gaat dit deel er eigenlijk deel van uitmaken en verschillende threads kunnen dan overlappend in het fragment Entry/Kritiek/Exit zitten. In de entry en exit-code worden de beschermde variabelen natuurlijk nog niet gebruikt, zodat het er vanuit de kritieke sectie uitziet alsof deze code een soort politieagent is die de toegang tot de kritieke sectie regelt. In figuur 2.1 zou je kunnen zeggen dat het programma de grote (mogelijk overlappende) intervallen ziet en de kritieke sectie de grijze (disjuncte) intervallen. Sequentialisatie kan alleen bereikt worden door threads op elkaar te laten wachten; immers, als een thread de varabelen wil gebruiken terwijl een andere kritiek is, kan de eerstgenoemde pas verder als de tweede het gebruik van de variabelen beëindigd heeft. Het wachten kan op

Gelijktijdigheid: Wederzijdse Uitsluiting & Synchronisatie Concurrency: Mutual Exclusion & Synchonization (5e ed: 5.1-5.2, Appendix A.

Gelijktijdigheid: Wederzijdse Uitsluiting & Synchronisatie Concurrency: Mutual Exclusion & Synchonization (5e ed: 5.1-5.2, Appendix A. Gelijktijdigheid: Wederzijdse Uitsluiting & Synchronisatie Concurrency: Mutual Exclusion & Synchonization (5e ed: 51-52, Appendix A1) Processes zijn meestal niet onafhankelijk Bijvoorbeeld: 2 processen

Nadere informatie

Gedistribueerd Programmeren - Samenvatting

Gedistribueerd Programmeren - Samenvatting Gedistribueerd Programmeren - Samenvatting Geertjan van Vliet Disclaimer: Aan deze teksten kunnen geen rechten ontleend worden. Bepaalde passages zijn de visie van de auteur en niet die van de docent.

Nadere informatie

HOOFDSTUK 3. Imperatief programmeren. 3.1 Stapsgewijs programmeren. 3.2 If Then Else. Module 4 Programmeren

HOOFDSTUK 3. Imperatief programmeren. 3.1 Stapsgewijs programmeren. 3.2 If Then Else. Module 4 Programmeren HOOFDSTUK 3 3.1 Stapsgewijs programmeren De programmeertalen die tot nu toe genoemd zijn, zijn imperatieve of procedurele programmeertalen. is het stapsgewijs in code omschrijven wat een programma moet

Nadere informatie

Programmeren in Java 3

Programmeren in Java 3 7 maart 2010 Deze les Zelf componenten maken Concurrency (multithreading): werken met threads levenscyclus van een thread starten tijdelijk onderbreken wachten stoppen Zelf componenten maken Je eigen component:

Nadere informatie

Tim Mallezie Architectuur van besturingssystemen: Vraag A2.

Tim Mallezie Architectuur van besturingssystemen: Vraag A2. Procesbeheer: kenmerken van moderne besturingssystemen. 1. Bespreek de (drie) meest typische kenmerken van moderne besturingssystemen. 2. In hoeverre beantwoorden UNIX, Linux en Windows NT hieraan? Geef

Nadere informatie

VERZAMELINGEN EN AFBEELDINGEN

VERZAMELINGEN EN AFBEELDINGEN I VERZAMELINGEN EN AFBEELDINGEN Het begrip verzameling kennen we uit het dagelijks leven: een bibliotheek bevat een verzameling van boeken, een museum een verzameling van kunstvoorwerpen. We kennen verzamelingen

Nadere informatie

TECHNISCHE UNIVERSITEIT EINDHOVEN ComputerSystemen Deeltentamen B (weken 6..9) vakcode 2M208 woensdag 19 Maart 2003, 9:00-10:30

TECHNISCHE UNIVERSITEIT EINDHOVEN ComputerSystemen Deeltentamen B (weken 6..9) vakcode 2M208 woensdag 19 Maart 2003, 9:00-10:30 TECHNISCHE UNIVERSITEIT EINDHOVEN ComputerSystemen Deeltentamen B (weken 6..9) vakcode 2M208 woensdag 19 Maart 2003, 9:00-10:30 Algemene opmerkingen (lees dit!): - Dit tentamen duurt ANDERHALF UUR! - Dit

Nadere informatie

Als een PSD selecties bevat, deelt de lijn van het programma zich op met de verschillende antwoorden op het vraagstuk.

Als een PSD selecties bevat, deelt de lijn van het programma zich op met de verschillende antwoorden op het vraagstuk. HOOFDSTUK 3 3.1 Stapsgewijs programmeren In de vorige hoofdstukken zijn programmeertalen beschreven die imperatief zijn. is het stapsgewijs in code omschrijven wat een programma moet doen, net als een

Nadere informatie

ICT Infrastructuren: Processen en Threads. 18 november 2013 David N. Jansen

ICT Infrastructuren: Processen en Threads. 18 november 2013 David N. Jansen ICT Infrastructuren: Processen en Threads 18 november 2013 David N. Jansen Datum en Ajd van werkcollege na overleg met de aanwezigen: donderdag 8:45 10:30 Leerdoel voor vandaag. Stallings hoofdst 2 4 Hoofddoelen

Nadere informatie

1 Inleiding in Functioneel Programmeren

1 Inleiding in Functioneel Programmeren 1 Inleiding in Functioneel Programmeren door Elroy Jumpertz 1.1 Inleiding Aangezien Informatica een populaire minor is voor wiskundestudenten, leek het mij nuttig om een stukje te schrijven over een onderwerp

Nadere informatie

recursie Hoofdstuk 5 Studeeraanwijzingen De studielast van deze leereenheid bedraagt circa 6 uur. Terminologie

recursie Hoofdstuk 5 Studeeraanwijzingen De studielast van deze leereenheid bedraagt circa 6 uur. Terminologie Hoofdstuk 5 Recursion I N T R O D U C T I E Veel methoden die we op een datastructuur aan kunnen roepen, zullen op een recursieve wijze geïmplementeerd worden. Recursie is een techniek waarbij een vraagstuk

Nadere informatie

Waarmaken van Leibniz s droom

Waarmaken van Leibniz s droom Waarmaken van Leibniz s droom Artificiële intelligentie Communicatie & internet Operating system Economie Computatietheorie & Software Efficiënt productieproces Hardware architectuur Electronica: relais

Nadere informatie

TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica

TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica Examen Operating Systemen (2R230) op vrijdag 26 augustus 2005, 14.00-17.00 uur. Het tentamen bestaat uit drie delen die apart worden

Nadere informatie

Een eenvoudig algoritme om permutaties te genereren

Een eenvoudig algoritme om permutaties te genereren Een eenvoudig algoritme om permutaties te genereren Daniel von Asmuth Inleiding Er zijn in de vakliteratuur verschillende manieren beschreven om alle permutaties van een verzameling te generen. De methoden

Nadere informatie

Toetsbundel Deel 1 Concurrency 10 december 2015, Gerard Tel, Niet verspreiden 1!.

Toetsbundel Deel 1 Concurrency 10 december 2015, Gerard Tel, Niet verspreiden 1!. Toetsbundel Deel 1 Concurrency 10 december 2015, Gerard Tel, Niet verspreiden 1!. Deze bundel bevat een collectie toetsvragen over het eerste deel van Concurrency. Je kunt deze bundel gebruiken voor je

Nadere informatie

1 Delers 1. 3 Grootste gemene deler en kleinste gemene veelvoud 12

1 Delers 1. 3 Grootste gemene deler en kleinste gemene veelvoud 12 Katern 2 Getaltheorie Inhoudsopgave 1 Delers 1 2 Deelbaarheid door 2, 3, 5, 9 en 11 6 3 Grootste gemene deler en kleinste gemene veelvoud 12 1 Delers In Katern 1 heb je geleerd wat een deler van een getal

Nadere informatie

start -> id (k (f c s) (g s c)) -> k (f c s) (g s c) -> f c s -> s c

start -> id (k (f c s) (g s c)) -> k (f c s) (g s c) -> f c s -> s c Een Minimaal Formalisme om te Programmeren We hebben gezien dat Turing machines beschouwd kunnen worden als universele computers. D.w.z. dat iedere berekening met natuurlijke getallen die met een computer

Nadere informatie

Belangrijkste ideeën/concepten uit OS, incl. proces

Belangrijkste ideeën/concepten uit OS, incl. proces Operating System Overview (Hfst 2) Wat is een OS? Wat was een OS? Evolutie van OS. OS als virtuele machine OS als beheerder van hulpbronnen (resources) Belangrijkste ideeën/concepten uit OS, incl. proces

Nadere informatie

WISKUNDE B -DAG 2002 1+ 1 = 2. maar en hoe nu verder? 29 november 2002

WISKUNDE B -DAG 2002 1+ 1 = 2. maar en hoe nu verder? 29 november 2002 - 0 - WISKUNDE B -DAG 2002 1+ 1 = 2 maar en hoe nu verder? 29 november 2002 De Wiskunde B-dag wordt gesponsord door Texas Instruments - 1 - Inleiding Snel machtverheffen Stel je voor dat je 7 25 moet uitrekenen.

Nadere informatie

Real-Time Systems (RTSYST)

Real-Time Systems (RTSYST) Real-Time Systems (RTSYST) Week 2 Process/Thread states ready running Wait for I/O or I/O or completion blocked / sleeping Scheduler = deel van OS dat de toestanden van processen/threads bepaald. OS gebruikt

Nadere informatie

n-queens minimale dominantie verzamelingen Chessboard Domination on Programmable Graphics Hardware door Nathan Cournik

n-queens minimale dominantie verzamelingen Chessboard Domination on Programmable Graphics Hardware door Nathan Cournik n-queens minimale dominantie verzamelingen Chessboard Domination on Programmable Graphics Hardware door Nathan Cournik Rick van der Zwet 4 augustus 2010 Samenvatting Dit schrijven zal

Nadere informatie

Nederlandse samenvatting (Dutch summary)

Nederlandse samenvatting (Dutch summary) Nederlandse samenvatting (Dutch summary) Ditproefschriftpresenteerteen raamwerk voorhetontwikkelenvanparallellestreaming applicaties voor heterogene architecturen met meerdere rekeneenheden op een chip.

Nadere informatie

CPU scheduling : introductie

CPU scheduling : introductie CPU scheduling : introductie CPU scheduling nodig bij multiprogrammering doel: een zo hoog mogelijke CPU-bezetting, bij tevreden gebruikers proces bestaat uit afwisselend CPU-bursts en I/O-bursts lengte

Nadere informatie

Getaltheorie I. c = c 1 = 1 c (1)

Getaltheorie I. c = c 1 = 1 c (1) Lesbrief 1 Getaltheorie I De getaltheorie houdt zich bezig met het onderzoek van eigenschappen van gehele getallen, en meer in het bijzonder, van natuurlijke getallen. In de getaltheorie is het gebruikelijk

Nadere informatie

Teamhandleiding DOMjudge (versie 2.2.0muKP) 31 mei 2008

Teamhandleiding DOMjudge (versie 2.2.0muKP) 31 mei 2008 judge Teamhandleiding DOMjudge (versie..0mukp) 31 mei 008 /\ DOM DOM judge Inhoudsopgave 1 Inleiding Samenvatting.1 Inlezen en wegschrijven............................... Insturen van oplossingen...............................3

Nadere informatie

DOMjudge teamhandleiding

DOMjudge teamhandleiding judge DOMjudge teamhandleiding Samenvatting /\ DOM DOM judge Hieronder staat de belangrijkste informatie kort samengevat. Dit is bedoeld om snel aan de slag te kunnen. We raden echter ten zeerste aan dat

Nadere informatie

Twaalfde college complexiteit. 11 mei 2012. Overzicht, MST

Twaalfde college complexiteit. 11 mei 2012. Overzicht, MST College 12 Twaalfde college complexiteit 11 mei 2012 Overzicht, MST 1 Agenda voor vandaag Minimum Opspannende Boom (minimum spanning tree) als voorbeeld van greedy algoritmen Overzicht: wat voor technieken

Nadere informatie

Bellen Zonder Zorgen

Bellen Zonder Zorgen Bellen Zonder Zorgen Je hebt het vast wel eens gehad. Ben je lekker aan het werk op je computer loopt hij ineens vast! En natuurlijk heb je het werk niet opgeslagen. Je probeert nog van alles om te redden

Nadere informatie

Modulewijzer InfPbs00DT

Modulewijzer InfPbs00DT Modulewijzer InfPbs00DT W. Oele 0 juli 008 Inhoudsopgave Inleiding 3 Waarom wiskunde? 3. Efficiëntie van computerprogramma s............... 3. 3D-engines en vectoranalyse................... 3.3 Bewijsvoering

Nadere informatie

Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft

Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft Bij dit tentamen mag je geen gebruik maken van hulpmiddelen zoals boek of slides. Dit

Nadere informatie

Geheugenbeheer. ICT Infrastructuren 2 december 2013

Geheugenbeheer. ICT Infrastructuren 2 december 2013 Geheugenbeheer ICT Infrastructuren 2 december 2013 Doelen van geheugenbeheer Reloca>e (flexibel gebruik van geheugen) Bescherming Gedeeld/gemeenschappelijk geheugen Logische indeling van procesonderdelen

Nadere informatie

Meetellen van vakken bij meerdere inschrijvingen - notitie voor specialisten HvA Reinier van der Neut / 20-03-2012

Meetellen van vakken bij meerdere inschrijvingen - notitie voor specialisten HvA Reinier van der Neut / 20-03-2012 Meetellen van vakken bij meerdere inschrijvingen - notitie voor specialisten HvA Reinier van der Neut / 20-03-2012 Wanneer een student inschrijvingen heeft op twee of meer verschillende opleidingen en

Nadere informatie

Installatie Handleiding voor Modelit Applicatieprogrammatuur

Installatie Handleiding voor Modelit Applicatieprogrammatuur Modelit Elisabethdreef 5 4101 KN Culemborg Telefoon +31 345 521121 info@modelit.nl www.modelit.nl Installatie Handleiding voor Modelit Applicatieprogrammatuur Datum 27 April 2007 Modelit KvK Rivierenland

Nadere informatie

3 De stelling van Kleene

3 De stelling van Kleene 18 3 De stelling van Kleene Definitie 3.1 Een formele taal heet regulier als hij wordt herkend door een deterministische eindige automaat. Talen van de vorm L(r) met r een reguliere expressie noemen we

Nadere informatie

Zelftest Informatica-terminologie

Zelftest Informatica-terminologie Zelftest Informatica-terminologie Document: n0947test.fm 01/07/2015 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is een zelf-test, waarmee u

Nadere informatie

Inleiding Digitale Techniek

Inleiding Digitale Techniek Inleiding Digitale Techniek Week 4 Binaire optellers, tellen, vermenigvuldigen, delen Jesse op den Brouw INLDIG/25-26 Optellen Optellen is één van meest gebruikte rekenkundige operatie in digitale systemen.

Nadere informatie

Digitale en analoge technieken

Digitale en analoge technieken Digitale en analoge technieken Peter Slaets February 14, 2006 Peter Slaets () Digitale en analoge technieken February 14, 2006 1 / 33 Computerarchitectuur 1 Processors 2 Primair geheugen 3 Secundair geheugen

Nadere informatie

8. Complexiteit van algoritmen:

8. Complexiteit van algoritmen: 8. Complexiteit van algoritmen: Voorbeeld: Een gevaarlijk spel 1 Spelboom voor het wespenspel 2 8.1 Complexiteit 4 8.2 NP-problemen 6 8.3 De oplossing 7 8.4 Een vuistregel 8 In dit hoofdstuk wordt het

Nadere informatie

In Katern 2 hebben we de volgende rekenregel bewezen, als onderdeel van rekenregel 4:

In Katern 2 hebben we de volgende rekenregel bewezen, als onderdeel van rekenregel 4: Katern 4 Bewijsmethoden Inhoudsopgave 1 Bewijs uit het ongerijmde 1 2 Extremenprincipe 4 3 Ladenprincipe 8 1 Bewijs uit het ongerijmde In Katern 2 hebben we de volgende rekenregel bewezen, als onderdeel

Nadere informatie

Concurrency in Java met threads. Java Threads. Voorbeelden concurrency in applicaties. Waarom concurrency in Java?

Concurrency in Java met threads. Java Threads. Voorbeelden concurrency in applicaties. Waarom concurrency in Java? Java Threads Concurrency in Java met threads Wat zijn threads? Hoe werken threads? Hoe werk je met threads in Java? Scheduling Synchronisatie In Java programma s is concurrency (aka parallellisme) mogelijk.

Nadere informatie

Datastructuren: stapels, rijen en binaire bomen

Datastructuren: stapels, rijen en binaire bomen Programmeermethoden Datastructuren: stapels, rijen en binaire bomen week 12: 23 27 november 2015 www.liacs.leidenuniv.nl/ kosterswa/pm/ 1 Inleiding In de informatica worden Abstracte DataTypen (ADT s)

Nadere informatie

Tentamen Discrete Wiskunde 1 10 april 2012, 14:00 17:00 uur

Tentamen Discrete Wiskunde 1 10 april 2012, 14:00 17:00 uur Tentamen Discrete Wiskunde 0 april 0, :00 7:00 uur Schrijf je naam op ieder blad dat je inlevert. Onderbouw je antwoorden, met een goede argumentatie zijn ook punten te verdienen. Veel succes! Opgave.

Nadere informatie

Zelftest Inleiding Programmeren

Zelftest Inleiding Programmeren Zelftest Inleiding Programmeren Document: n0824test.fm 22/01/2013 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST INLEIDING PROGRAMMEREN Deze

Nadere informatie

Flex_Rooster WERKBOEK. INTRODUCTIE iseries. Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen.

Flex_Rooster WERKBOEK. INTRODUCTIE iseries. Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen. Flex_Rooster WERKBOEK INTRODUCTIE iseries Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen. ICS Opleidingen Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt

Nadere informatie

Gegevens invullen in HOOFDLETTERS en LEESBAAR, aub. Belgische Olympiades in de Informatica (duur : maximum 1u15 )

Gegevens invullen in HOOFDLETTERS en LEESBAAR, aub. Belgische Olympiades in de Informatica (duur : maximum 1u15 ) OI 2010 Finale 12 Mei 2010 Gegevens invullen in HOOFDLETTERS en LEESBAAR, aub VOORNAAM :....................................................... NAAM :..............................................................

Nadere informatie

Vraag 1 (2 punten) (iii) Een lees-opdracht van virtueel adres 2148 seg 0, offset 2148 - idem

Vraag 1 (2 punten) (iii) Een lees-opdracht van virtueel adres 2148 seg 0, offset 2148 - idem Tentamen A2 (deel b) 24-06-2004 Geef (liefst beknopte en heldere) motivatie bij je antwoorden; dus niet enkel ja of nee antwoorden, maar ook waarom. Geef van berekeningen niet alleen het eindresultaat,

Nadere informatie

in1671 - Operating System Concepten Doel van een Operating System Interrupts 3-Lagen model spooling (Simultaneous Peripheral Operation On Line)

in1671 - Operating System Concepten Doel van een Operating System Interrupts 3-Lagen model spooling (Simultaneous Peripheral Operation On Line) in1671 - Operating System Concepten Doel van een Operating System drs J.W.J. Heijnsdijk Faculteit EWI, kamer 09.280 (Mekelweg 4) tel. 85804 email: Heijnsdijk@ewi.tudelft.nl Wat is een Operating System?

Nadere informatie

in1671 - Operating System Concepten

in1671 - Operating System Concepten in1671 - Operating System Concepten drs J.W.J. Heijnsdijk Faculteit EWI, kamer 09.280 (Mekelweg 4) tel. 85804 email: Heijnsdijk@ewi.tudelft.nl 2005 1-1 Doel van een Operating System Wat is een Operating

Nadere informatie

Het besturingssysteem of operating system, vaak afgekort tot OS is verantwoordelijk voor de communicatie van de software met de hardware.

Het besturingssysteem of operating system, vaak afgekort tot OS is verantwoordelijk voor de communicatie van de software met de hardware. Het besturingssysteem of operating system, vaak afgekort tot OS is verantwoordelijk voor de communicatie van de software met de hardware. Het vormt een schil tussen de applicatiesoftware en de hardware

Nadere informatie

Oplossingen Datamining 2II15 Juni 2008

Oplossingen Datamining 2II15 Juni 2008 Oplossingen Datamining II1 Juni 008 1. (Associatieregels) (a) Zijn de volgende beweringen juist of fout? Geef een korte verklaring voor alle juiste beweringen en een tegenvoorbeeld voor alle foute be-weringen:

Nadere informatie

17 Operaties op bits. 17.1 Bitoperatoren en bitexpressies

17 Operaties op bits. 17.1 Bitoperatoren en bitexpressies 17 Operaties op bits In hoofdstuk 1 is gezegd dat C oorspronkelijk bedoeld was als systeemprogrammeertaal om het besturingssysteem UNIX te implementeren. Bij dit soort toepassingen komt het voor dat afzonderlijke

Nadere informatie

PROS1E1 Gestructureerd programmeren in C Dd/Kf/Bd

PROS1E1 Gestructureerd programmeren in C Dd/Kf/Bd Inhoudsopgave 1 Inleiding... 1 2 Toekenning- en herhalingsopdrachten (for loop)... 2 2.1 De wet van Ohm... 3 2.2 De spaarrekening... 3 2.3 De transformator... 3 3 Keuze- en herhalingsopdrachten (if, switch,

Nadere informatie

Variabelen en statements in ActionScript

Variabelen en statements in ActionScript Ontwikkelen van Apps voor ios en Android Variabelen en statements in ActionScript 6.1 Inleiding Als we het in de informatica over variabelen hebben, bedoelen we een stukje in het geheugen van de computer

Nadere informatie

Uitleg. Welkom bij de Beverwedstrijd 2006. Je krijgt 15 vragen, die je in maximaal 45 minuten moet beantwoorden.

Uitleg. Welkom bij de Beverwedstrijd 2006. Je krijgt 15 vragen, die je in maximaal 45 minuten moet beantwoorden. Uitleg Welkom bij de Beverwedstrijd 2006 Je krijgt 15 vragen, die je in maximaal 45 minuten moet beantwoorden. Je krijgt 5 vragen van niveau A, 5 vragen van niveau B en 5 vragen van niveau C. Wij denken

Nadere informatie

Het relaas van de beginnende programmeur. Het hoe en waarom van de assistent

Het relaas van de beginnende programmeur. Het hoe en waarom van de assistent Het relaas van de beginnende programmeur Het hoe en waarom van de assistent 1. Help, mijn code doet niks... Mogelijke oplossingen: Heb je op run geduwd (groene pijltje)? Zolang je niet op 'run' duwt, kent

Nadere informatie

High Performance Computing

High Performance Computing High Performance Computing Kristian Rietveld (krietvel@liacs.nl, kamer 138) Groep Computer Systems High-Performance Computing Optimizing compilers (generieke codes, maar ook specifieke rekenkernels). Parallel

Nadere informatie

WELKOM BIJ BOMBERBOT! LES 2: SEQUENTIES I LES 2: SEQUENTIES I WAAR GAAT DEZE LES OVER? INTRODUCTIE

WELKOM BIJ BOMBERBOT! LES 2: SEQUENTIES I LES 2: SEQUENTIES I WAAR GAAT DEZE LES OVER? INTRODUCTIE WELKOM BIJ BOMBERBOT! Bij onze lessen horen ook nog een online game, waarin de leerlingen de concepten die ze geleerd krijgen direct moeten toepassen, en een online platform, waarin u de voortgang van

Nadere informatie

Universiteit Leiden Opleiding Informatica

Universiteit Leiden Opleiding Informatica Internal Report 2010 08 February 2011 Universiteit Leiden Opleiding Informatica Multithreading voor iedereen Jaron Viëtor BACHELOR THESIS Leiden Institute of Advanced Computer Science (LIACS) Leiden University

Nadere informatie

Hoofdstuk 7: Werken met arrays

Hoofdstuk 7: Werken met arrays Programmeren in Microsoft Visual Basic 6.0, lessenserie voor het voortgezet onderwijs HAVO/VWO David Lans, Emmauscollege, Marnix Gymnasium Rotterdam, januari 2004 Hoofdstuk 7: Werken met arrays 7.0 Leerdoel

Nadere informatie

Polyatheorie. Erik Verraedt 2011-2012

Polyatheorie. Erik Verraedt 2011-2012 2011-2012 Inhoudsopgave 1 Inleiding 4 2 Enkele telproblemen 5 2.1 Probleem 1........................................ 5 2.2 Probleem 2........................................ 5 2.3 Probleem 3........................................

Nadere informatie

Uitwerkingen Sum of Us

Uitwerkingen Sum of Us Instant Insanity Uitwerkingen Sum of Us Opgave A: - Opgave B: Voor elk van de vier kubussen kun je een graaf maken die correspondeert met de desbetreffende kubus. Elk van deze grafen bevat drie lijnen.

Nadere informatie

Om te kijken of x, y, z samen een driehoek specificeren hoeven we alleen nog maar de driehoeksongelijkheid te controleren: x, y, z moeten voldoen

Om te kijken of x, y, z samen een driehoek specificeren hoeven we alleen nog maar de driehoeksongelijkheid te controleren: x, y, z moeten voldoen Feedback Software Testing, Opdrachten Week 1 Driehoek-test Deze opdracht is in het algemeen zeer goed uitgevoerd. Algemeen valt in vergelijking met vorig jaar op dat de ingeleverde oplossingen veel minder

Nadere informatie

Voorbeeld casus mondeling college-examen

Voorbeeld casus mondeling college-examen Voorbeeld casus mondeling college-examen Examenvak en niveau informatica vwo Naam kandidaat Examennummer Examencommissie Datum Voorbereidingstijd Titel voorbereidingsopdracht 20 minuten van analoog naar

Nadere informatie

Installatie Software - Opdrachten Les 2

Installatie Software - Opdrachten Les 2 Installatie Software - Opdrachten Les 2 ROC van Amsterdam Gooi en Vechtstreek Naam: Klas: Datum: 2010 Jansn 1 van 11 is een operating system dat ten grondslag ligt aan de verschillende versies van Windows.

Nadere informatie

Over Plantinga s argument voor de existentie van een noodzakelijk bestaand individueel ding. G.J.E. Rutten

Over Plantinga s argument voor de existentie van een noodzakelijk bestaand individueel ding. G.J.E. Rutten 1 Over Plantinga s argument voor de existentie van een noodzakelijk bestaand individueel ding G.J.E. Rutten Introductie In dit artikel wil ik het argument van de Amerikaanse filosoof Alvin Plantinga voor

Nadere informatie

Inhoud. Introductie tot de cursus

Inhoud. Introductie tot de cursus Inhoud Introductie tot de cursus 1 Inleiding 7 2 Voorkennis 7 3 Het cursusmateriaal 7 4 Structuur, symbolen en taalgebruik 8 5 De cursus bestuderen 9 6 Studiebegeleiding 10 7 Huiswerkopgaven 10 8 Het tentamen

Nadere informatie

UBC op Microsoft Windows 64-bits

UBC op Microsoft Windows 64-bits UBC op Microsoft Windows 64-bits Inleiding Op de 64-bits varianten van Windows werkt de UBC (en vele andere pakketten) op een andere manier dan op de oudere 32-bits varianten van deze Windows versies.

Nadere informatie

4EE11 Project Programmeren voor W. College 3, 2008 2009, Blok D Tom Verhoeff, Software Engineering & Technology, TU/e

4EE11 Project Programmeren voor W. College 3, 2008 2009, Blok D Tom Verhoeff, Software Engineering & Technology, TU/e 4EE11 Project Programmeren voor W College 3, 2008 2009, Blok D Tom Verhoeff, Software Engineering & Technology, TU/e 1 Onderwerpen Grotere programma s ontwerpen/maken Datastructuren en algoritmes 2 Evolutie,

Nadere informatie

Activiteit 1. Tel de punten Binaire Getallen. Samenvatting. Kerndoelen. Vaardigheden. Leeftijd. Materiaal

Activiteit 1. Tel de punten Binaire Getallen. Samenvatting. Kerndoelen. Vaardigheden. Leeftijd. Materiaal Activiteit 1 Tel de punten Binaire Getallen Samenvatting Data in de computer worden opgeslagen als een serie van nullen en enen. Hoe kunnen we woorden en getallen weergeven met alleen deze twee symbolen?

Nadere informatie

Algoritme noteren? Algoritmen voor de computer worden vastgelegd met behulp van een programmeertaal.

Algoritme noteren? Algoritmen voor de computer worden vastgelegd met behulp van een programmeertaal. Programmeertalen Algoritme noteren? Algoritmen voor de computer worden vastgelegd met behulp van een programmeertaal. Taal // machine De geschiedenis van de programmeertalen loopt parallel met de geschiedenis

Nadere informatie

Albert-Jan de Croes & Stefan Willemink V4C Docent: Mevrouw van Uden

Albert-Jan de Croes & Stefan Willemink V4C Docent: Mevrouw van Uden Albert-Jan de Croes & Stefan Willemink V4C Docent: Mevrouw van Uden 1 Inhoud Inhoud... 2 Inleiding... 3 Wat doet een besturingsysteem, en hoe werkt het?... 3 Algemene informatie... 3 Taken van een besturingssysteem...

Nadere informatie

The End of an Architectural Era

The End of an Architectural Era The End of an Architectural Era M. Stonebraker, S. Madden, D. J. Abadi, S. Harizopoulos, N. Hachem, P. Helland Jorn Van Loock Inleiding Oorsprong relationele DBMS IBM System R (1974) DB2 Sybase SQL Server

Nadere informatie

ONTWERP VAN GEDISTRIBUEERDE SOFTWARE ACADEMIEJAAR 2009-2010 1 STE EXAMENPERIODE, 15 JANUARI 2010, 14U 17U30 VRAAG 1: INLEIDENDE BEGRIPPEN[20 MIN]

ONTWERP VAN GEDISTRIBUEERDE SOFTWARE ACADEMIEJAAR 2009-2010 1 STE EXAMENPERIODE, 15 JANUARI 2010, 14U 17U30 VRAAG 1: INLEIDENDE BEGRIPPEN[20 MIN] ONTWERP VAN GEDISTRIBUEERDE SOFTWARE ACADEMIEJAAR 2009-2010 1 STE EXAMENPERIODE, 15 JANUARI 2010, 14U 17U30 Naam :.. Richting :.. Opmerkingen vooraf : - werk verzorgd en duidelijk, zodat er geen dubbelzinnigheden

Nadere informatie

Een combinatorische oplossing voor vraag 10 van de LIMO 2010

Een combinatorische oplossing voor vraag 10 van de LIMO 2010 Een combinatorische oplossing voor vraag 10 van de LIMO 2010 Stijn Vermeeren (University of Leeds) 16 juni 2010 Samenvatting Probleem 10 van de Landelijke Interuniversitaire Mathematische Olympiade 2010vraagt

Nadere informatie

TECHNISCHE UNIVERSITEIT EINDHOVEN FACULTEIT DER TECHNISCHE NATUURKUNDE

TECHNISCHE UNIVERSITEIT EINDHOVEN FACULTEIT DER TECHNISCHE NATUURKUNDE TECHNISCHE UNIVERSITEIT EINDHOVEN FACULTEIT DER TECHNISCHE NATUURKUNDE Tentamen Computers bij fysische experimenten (3BB20) op dinsdag 25 oktober 2005 Het tentamen duurt 90 minuten en wordt gemaakt zonder

Nadere informatie

HET BESTURINGSSYSTEEM

HET BESTURINGSSYSTEEM HET BESTURINGSSYSTEEM Een besturingssysteem (ook wel: bedrijfssysteem, in het Engels operating system of afgekort OS) is een programma (meestal een geheel van samenwerkende programma's) dat na het opstarten

Nadere informatie

Systeemarchitectuur. Piet van Oostrum. herziene versie november 2005. Departement Informatica

Systeemarchitectuur. Piet van Oostrum. herziene versie november 2005. Departement Informatica Systeemarchitectuur Piet van Oostrum herziene versie november 2005 Departement Informatica Padualaan 14 3584 CD Utrecht Corr. adres: Postbus 80.089 3508 TB Utrecht Telefoon 030-2531454 Fax 030-2513791

Nadere informatie

Krulgetallen en een heel langzaam stijgende rij. D. C. Gijswijt

Krulgetallen en een heel langzaam stijgende rij. D. C. Gijswijt krulgetal.tex 11 oktober 2015 ²J1 Krulgetallen en een heel langzaam stijgende rij. D. C. Gijswijt Krulgetallen Bekijk eens het volgende rijtje: 2, 1, 2, 3, 2, 3, 1, 2, 3, 2, 3, 1, 2, 3, 2, 3. Dit rijtje

Nadere informatie

Software Mobiliteit. UAMS - 6 maart 2001. Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac.

Software Mobiliteit. UAMS - 6 maart 2001. Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac. Software Mobiliteit Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac.be/~tjdhondt p. 1 Overzicht Stelling Objecttechnologie Distributie Mobiliteit Evolutie Besluit p.

Nadere informatie

Opgaven bij Hoofdstuk 3 - Productiesystemen

Opgaven bij Hoofdstuk 3 - Productiesystemen Opgaven bij Hoofdstuk 3 - Productiesystemen Top-down inferentie In de opgaven in deze paragraaf over top-down inferentie wordt aangenomen dat de feitenverzameling alleen feiten bevat die als getraceerd

Nadere informatie

Van Poort tot Pipeline. Ben Bruidegom & Wouter Koolen-Wijkstra AMSTEL Instituut Universiteit van Amsterdam

Van Poort tot Pipeline. Ben Bruidegom & Wouter Koolen-Wijkstra AMSTEL Instituut Universiteit van Amsterdam Van Poort tot Pipeline Ben Bruidegom & Wouter Koolen-Wijkstra AMSTEL Instituut Universiteit van Amsterdam Van Poort tot Pipeline Pipeline processor One cycle machine Calculator File of registers Assembly

Nadere informatie

VAN HET PROGRAMMEREN. Inleiding

VAN HET PROGRAMMEREN. Inleiding OVERZICHT VAN HET PROGRAMMEREN Inleiding Als je leert programmeren lijkt het nogal overweldigend om die eerste stappen te doorworstelen. Er zijn dan ook heel wat programmeertalen (Java, Ruby, Python, Perl,

Nadere informatie

Programmeren in Java les 3

Programmeren in Java les 3 4 september 2015 Deze les korte herhaling vorige week loops methodes Variabelen Soorten variabelen in Java: integer: een geheel getal, bijv. 1,2,3,4 float: een gebroken getal, bijv. 3.1415 double: een

Nadere informatie

Inhoud. Introductie tot de cursus

Inhoud. Introductie tot de cursus Inhoud Introductie tot de cursus 1 De functie van de cursus 7 2 De inhoud van de cursus 7 2.1 Voorkennis 7 2.2 Leerdoelen van de cursus 8 2.3 Opbouw van de cursus 8 3 Leermiddelen en wijze van studeren

Nadere informatie

Gaap, ja, nog een keer. In één variabele hebben we deze formule nu al een paar keer gezien:

Gaap, ja, nog een keer. In één variabele hebben we deze formule nu al een paar keer gezien: Van de opgaven met een letter en dus zonder nummer staat het antwoord achterin. De vragen met een nummer behoren tot het huiswerk. Spieken achterin helpt je niets in het beter snappen... 1 Stelling van

Nadere informatie

Module 3: Scratch programmeren: is het logisch of is het niet logisch?

Module 3: Scratch programmeren: is het logisch of is het niet logisch? Module 3: Scratch programmeren: is het logisch of is het niet logisch? Inhoudsopgave Module 3: Scratch programmeren: is het logisch of is het niet logisch?...1 Wat is een computerprogramma eigenlijk?...2

Nadere informatie

Numerieke aspecten van de vergelijking van Cantor. Opgedragen aan Th. J. Dekker. H. W. Lenstra, Jr.

Numerieke aspecten van de vergelijking van Cantor. Opgedragen aan Th. J. Dekker. H. W. Lenstra, Jr. Numerieke aspecten van de vergelijking van Cantor Opgedragen aan Th. J. Dekker H. W. Lenstra, Jr. Uit de lineaire algebra is bekend dat het aantal oplossingen van een systeem lineaire vergelijkingen gelijk

Nadere informatie

Digitale technieken Deeltoets II

Digitale technieken Deeltoets II Digitale technieken Deeltoets II André Deutz 11 januari, 2008 De opgaven kunnen uiteraard in een willekeurige volgorde gemaakt worden geef heel duidelijk aan op welke opgave een antwoord gegegeven wordt.

Nadere informatie

imangine Stichting SchoolLan

imangine Stichting SchoolLan imangine Stichting SchoolLan 25 augustus 2004 Inhoudsopgave 1 Introductie 3 2 Werking 4 2.1 Opstarten werkstation....................... 4 2.2 imangine activeren........................ 4 3 Maken van spiegel

Nadere informatie

9. Strategieën en oplossingsmethoden

9. Strategieën en oplossingsmethoden 9. Strategieën en oplossingsmethoden In dit hoofdstuk wordt nog even terug gekeken naar alle voorgaande hoofdstukken. We herhalen globaal de structuren en geven enkele richtlijnen voor het ontwerpen van

Nadere informatie

voegtoe: eerst methode bevat gebruiken, alleen toevoegen als bevat() false is

voegtoe: eerst methode bevat gebruiken, alleen toevoegen als bevat() false is PROEF-Tentamen Inleiding programmeren (IN1608WI), X januari 2010, 9.00-11.00, Technische Universiteit Delft, Faculteit EWI, Afdeling 2. Open boek tentamen: bij het tentamen mag alleen gebruik worden gemaakt

Nadere informatie

Werken op afstand via internet

Werken op afstand via internet HOOFDSTUK 12 Werken op afstand via internet In dit hoofdstuk wordt uitgelegd wat er nodig is om op afstand met de ROS artikel database te kunnen werken. Alle benodigde programma s kunnen worden gedownload

Nadere informatie

WAVIX Installatie Handleiding

WAVIX Installatie Handleiding Modelit Rotterdamse Rijweg 126 3042 AS Rotterdam Telefoon +31 10 4623621 info@modelit.nl www.modelit.nl in opdracht van RIKZ WAVIX Installatie Handleiding Modelit KvK Rotterdam 24290229 Datum 27 September

Nadere informatie

Dit document bevat informatie over make bij het eerstejaars college Programmeermethoden, Universiteit Leiden, najaar 2010, zie

Dit document bevat informatie over make bij het eerstejaars college Programmeermethoden, Universiteit Leiden, najaar 2010, zie Dit document bevat informatie over make bij het eerstejaars college Programmeermethoden, Universiteit Leiden, najaar 2010, zie www.liacs.nl/home/kosters/pm/ Met dank aan allen die aan deze tekst hebben

Nadere informatie

opgaven formele structuren deterministische eindige automaten

opgaven formele structuren deterministische eindige automaten opgaven formele structuren deterministische eindige automaten Opgave. De taal L over het alfabet {a, b} bestaat uit alle strings die beginnen met aa en eindigen met ab. Geef een reguliere expressie voor

Nadere informatie

1.7 Ontleding van het eerste programma... 14

1.7 Ontleding van het eerste programma... 14 Inhoudsopgave 1 Inleiding 1 1.1 Wat kan je met Java doen?..................... 1 1.2 Over Java............................... 3 1.3 Gebruik van dit boek......................... 5 1.4 Installatie...............................

Nadere informatie

RAM geheugens. Jan Genoe KHLim. Situering RAM-geheugens. Geheugens. Halfgeleider Geheugens. Willekeurig toegankelijk geheugen

RAM geheugens. Jan Genoe KHLim. Situering RAM-geheugens. Geheugens. Halfgeleider Geheugens. Willekeurig toegankelijk geheugen Jan Genoe KHLim Situering RAM-geheugens Geheugens Halfgeleider Geheugens Serieel toegankelijk geheugen Willekeurig toegankelijk geheugen Read Only Memory ROM Random Access Memory RAM Statische RAM SRAM

Nadere informatie

Dynamische Patiënt Simulaties via Windows Based Terminal Testverslag van fase 2 van het ICT project

Dynamische Patiënt Simulaties via Windows Based Terminal Testverslag van fase 2 van het ICT project Dynamische Patiënt Simulaties via Windows Based Terminal Testverslag van fase 2 van het ICT project Doelstelling Het doel van fase 2 van het project Interfacultaire communicatie training via een virtuele

Nadere informatie

Computing machinery and Intelligence. A. M. Turing. Samengevat door: Matthijs Melissen

Computing machinery and Intelligence. A. M. Turing. Samengevat door: Matthijs Melissen Computing machinery and Intelligence A. M. Turing Samengevat door: Matthijs Melissen Ik stel voor om de vraag Kunnen machines denken? te behandelen door te kijken naar een zogenaamd imitatiespel. Hiervoor

Nadere informatie

APPLICATIEBOUW 1E COLLEGE: INTRODUCTIE. Onderdeel van SmartProducts

APPLICATIEBOUW 1E COLLEGE: INTRODUCTIE. Onderdeel van SmartProducts APPLICATIEBOUW 1E COLLEGE: INTRODUCTIE Onderdeel van SmartProducts EVEN VOORSTELLEN DOCENT Fjodor van Slooten N208 (Horstring Noord) F.vanSlooten@utwente.nl Assistentie door: Hans Tragter, Marc Schreiber,

Nadere informatie