Algorithms and Architectures II Jens Myrup Pedersen (JMP), Rasmus Løvenstein Olsen (RLO)

Algorithms and Architectures II Jens Myrup Pedersen (JMP), Rasmus Løvenstein Olsen (RLO) Mm3: Algorithm examples: Advanced backtracking, min-max, algorithms for task scheduling - February 23, 2009

Algorithms and Architectures II 1. Processor and Storage Architecture (JMP) 2. Vehicular on-board networks and applications (RLO) 3. Algorithm examples: Advanced backtracking, min-max, task scheduling (RLO) 4. Complexity and complexity classes (RLO) 5. Complexity and complexity classes 2 + algorithms for task scheduling (RLO) 6. Advanced data structures 1 (JMP) 7. Advanced data structures 2 (JMP) 8. Graph algorithms 1 (JMP) 9. Graph algorithms 2 (JMP) 10. Guest Lecture by Rasmus H. Nielsen: Complex Problems in Network Planning

Dagens program Binære træer og min/max søgning Backtracking Spanning tree Task skedulering Opgaver

Binære træer 5 2 3 3 7 5 7 8 2 5 8 4 Formindskede nøgletal Forøgede nøgletal Egenskaber ved binære træer: Lad x være et knudepunkt i et binært søge træ Hvis y er en knude i det venstre deltræ af x, så er key[y] key[x]. Hvis y er en knude i det højre deltræ af x, så er key[x] key[y]

Intern data repræsentation af binære træer A D B E C A B C D E Ved anvendelse af (dobbelt) linked lister kan man simpelt repræsentere binære træer Eksempelvis til søgning af data elementer

Operationer på binære træer; indsæt en knude 12 5 18 2 9 15 19 13 17 Flyt knuden ned og sammenlign key x med key[y] indtil der ikke er flere undertræer tilbage Det indsatte element er derefter en underknude

Operations on binary trees Delete node 12 5 16 3 12 20 10 13 18 23 6 7

Brugs eksempel - Opdeling af areal i datastruktur 1. A er roden af træet og hele polygonet 2. A splittes ind i B og C 3. B splittes ind i D og E. 4. D splittes ind i F og G, der er konvekse og derfor bliver blade i træet

Forespørgsler i binære træer Lede efter en specifik knude (key[y]) ved brug af nøgle x Hvis key x = key[y] så stop; knuden er fundet Hvis key x < key[y] så søg i venstre undertræ Hvis key x > key[y] så søg i højre undertræ Hvis der ikke er flere undertræer tilbage, så er der intet resultat Søgningen kan foretages på O(h) tid (h er højden af træet) Maximum og minimum søgninger Minimum søgning: Følg træets venstre side intil slutningen Maximum søgning: Følg træets højre side indtil slutningen Søgningen kan foretages på O(h) tid (h er højden af træet)

Backtracking Hvad er problemet? Hvad nu hvis vi ikke har nogen nøgler der tillader os at udøve søgning i et binært træ F.eks. Et problem er blevet nedbrudt i et sæt af mulige løsninger, og nu har vi behov for at finde den bedste løsning givet et sæt af begrænsinger

Eksempel: Dronninge problemet Betragt et n x n skakbræt, og placeringen af dronningen q på brættet uden at denne truer andre dronninger allerede på brættet: Ø Ø ØØ Ø Ø En dronning truer mange felter Løsningsrummet er givet ved {1,2,3,,n} n Efterprøvning af alle mulige løsninger giver n n muligheder, men ved at indse at to dronninger ikke kan være i samme række/kolonne reducerer det til n! muligheder.

Eksempel: Convex hull (Graham s Scan) Problemet går ud på at konstruere den korteste polygon der sammenlukker et givet sæt at punkter i et plan Gennegå punkter i en eller anden orden, tilføj dem til en partiel løsning ved at lave et knæk på mindre end 180 grader, og backtracke løsningen når der laves et knæk der er større Gennemgå nu mulige løsninger Intuitivt Start med ekstreme punkter Algoritmen kræver O(nLog(n)) tid for at sortere punkterne, og O(n) tid til at udvælge et passende undersæt

Backtracking En potentiel løsning er givet ved et sæt S={v 1,v 2,..,v n } Try(S) Is S a solution Yes Return S No For each v in S, do: No Is {v 1,v 2,..,v n, v} Acceptable? Yes Try {v 1,v 2,..,v n, v} Yes Is S!= Ø Return S No

Karakteristika ved backtracking Backtracking er anvendeligt ved gennenmgang i et løsningsrum Identifikation af problemet, er den vigtigste del i løsningen Beskrivelse og identifikation af regler er nødvendige, men ikke nødvendigvis nemt! Gode regler kan nem reducere antallet af iterationer der er nødvendige for at udføre proceduren

Graph definitions En graf er defineret ved G=(V,E) V: sæt af linjer E VxV: Sæt af kanter Ensrettet graf: (v 1,v 2 ) E (v 2,v 1 ) E Basale operationer på grafer På linjer: Add/Delete/Find På kanter: Add/Delete/Find En sti er defineret ved := En sekvens af kanter P(v 1 ->v n )={(v 1,v 2 ), (v 2,v 3 ), (v 3,v 4 ),.., (v n-1,v n )} Sti længden er n Applikationseksempler Routing i computer netværk Repræsentation og manipulation af (endelige) automataer (fortolkere, compilers) Repræsentation af semantiske relationer

Et ord om grådige algoritmer Grådige algoritmer vælger altid den mulighed der ser bedst ud på et givet tidspunkt De leder ikke altid til en optimal løsning, men i mange tilfælge gør de

Minimum spanning tree Problemet er at forbinde et træ med mindst mulig pris w( T ) = ( u, v) T w( u, v) a 4 8 11 b h 7 8 1 i 2 6 c g 7 4 2 d f 14 9 10 e Eksempel på applikationer: Printudlæg for elektronik hardware, Planlægning af netværk Rutning i netværk

At gro et spanning tree A er et undersæt af et spanning tree, T Generiske algoritmer til at genere et minimums spanning tree 1 A Ø 2 while A does not form a spanning tree 3 do find an edge (u,v) that is safe for A 4 A A {(u,v)} 5 return A Problemet er at finde en kant der er sikker for A Kruskal s algorithm Prim s algorithm

Kruskal s algorithm Brute force metode til at konstruere et spanning tree Ideen er at bygget et sæt af kanter E ved grådighed ( lokale beslutninger) Algoritmen ser således ud 1 A Ø 2 for each vertex v V[G] do MAKE-SET(v) 3 sort edges of E into increasing cost by w 4 for each edge (u,v) E do if FIND-SET(u) FIND-SET(v) then A A {(u,v)} UNION(u,v) 5 return A a 4 8 11 b h 7 8 1 i 2 6 c g 7 4 2 d f 14 9 10 e

Prim s algorithm Brute force metode der vokser en løsning Alle kanter der ikke befinder sig i et træ, er placeret i en min-prioritets kø, Q A = {( v, π[ v]) : v V { r} Q} Slutmålet med algoritmen opnås når flg. krav er opnået A = {( v, π[ v]) : v V { r}} a 4 8 11 b h 7 1 8 i 2 6 c g 7 1 for each u V[G] do key[u] π[u] NIL 2 key[r] 0 3 Q V[G] 4 while Q Ø do u EXTRACT-MIN(Q) for each v Adj[u] do if v Q and w(u,v)<key[v] then π[v] u key[v] w(u,v) 2 4 d f 14 9 10 e

Egenskaber ved de to algoritmer Udførselstid for de to algoritmer Kruskal s algorithm O(E log V) Prim s algorithm (afhængig af hvordan Q er implementeret) Adjacency matrix: O(V 2 ) Binær heap: O(E log V) Fibonacci heap: O(E+V log V) Prim s algorithm indeholder et træ under hele udførslen, mens Kruskal s algoritme ikke gør

Task skedulering Introduktiont til problemstillingen Basale strategier for job planlægning og eksekvering Realtids planlægning Job interaktion og kommunikation Multi processor job planlægning

Introduktion til task schedulering Anvendelse af computer systemer idag kræver vi At der kan køre mere end en proces ad gangen At de bliver kørt fornuftigt, så det virker som parrallelitelt (pseudo parralellitet ved enkelt CPU systemer) Ved netværk har vi efterhånden også samme krav Vi vil gerne have oplevelsen af et enkelt system udfører vores opgaver

Løsningen er operativ systemer Hvorfor har vi et behov for operativ systemer? At eksekvere flere applikationer/services på en enkelt computer er ikke muligt uden nogen form for kontrol af CPU en Hvad gør det godt for? Job håndtering Hukommelsesstyring Diskette og fil system Device drivers Netværk Sikkerhed Grafiske bruger flader Eksempler på eksisterende OS Windows, MacOS, Unix, Linux, Solaris, TinyOS, og mange flere Basalt set: Et OS er en ressource manager, med CPU en som den vigtigste ressource!

Et ord om response tider Decisekunder Forventede response tider ved reaktion fra tryk på keyboard Interaktion med en mus og skærm Brøkdele af sekunder Bestemte typer af tankekrævende arbejde, f.eks. grafik design eller spil Mindre end to sekunder Tilfælde hvor brugeren skal huske information i mellemliggende applikations interaktioner Mellem 2 og 4 sekunder Kræver høj koncentration af brugeren; kan måske være acceptabelt i nogle situationer Mere end 4 sekunder Generelt ikke acceptabelt, og vil typisk lede til frustrationer hos brugeren Mere end 15 sekunder Utolerable, men der er nogle situationer hvor det er ok, f.eks. i et skak program Brugeren bør generelt gives en chance for at gøre andre ting imens Source: Martin, J., Principles of Data Communication. Englewood Cliffs, NJ: Prentice Hall, 1988

Planlægningsproblem af opgaver At en opgave skal udføres, betyder IKKE at vi kan vente i uendelighed Blød realtid: Bruger interaktion, video, audio Hård realtid: Kontrol og styre systemer til f.eks. biler, robotter,... Et sæt af enhedsopgaver, S={a 1, a 2, a 3,., a n } Et sæt af deadlines D={d 1, d 2,., d n } Hver deadline overholder: 1 d i n Job a i er defineret ved d i Et sæt af positive vægtninger, straffe eller prioriteringer W={w 1, w 2,, w n } En straf w i er givet hvis Job a i ikke overholder deadline d i Problemet er nu, i hvilken orden af opgaver S skal de enkelte jobs udføres?

Eksempel på job planlægning a i 1 2 3 4 5 6 7 d i 4 2 4 3 1 4 6 w i 70 60 50 40 30 20 10 Ved at anvende den grådige algoritme, GREEDY, kan vi finde et svar 1. A Ø 2. Sort S[M] into monotonically decreasing order by weight 3. for each x S[M] do if A {x} l[m] then A A {x} 4. return A a 5 og a 6 vil blive afvist, og udførelsesordenen vil blive <a 2, a 4, a 1, a 3, a 7, a 5, a 6 > Prisen for at afvise a 5 og a 6 bliver a 5 +a 6 =50

Job planlægning, et eksempel Task 1 Task 2 Task 3 Task 4 Time Task running Dispatcher Task ready Task Blocked Task not started

En model af et programs tilstand i et OS Admit Dispatch New Ready Running Exit Time-out Release Event occurs Blocked Event wait

Proces context og contex skift En proces er beskrevet af en blok af data, der typisk indeholder bl.a. Et ID nummer der identificerer processen Pointere til programmets lokation og hvor processoren er kommet til Register indhold Tilstand af forskellige flag og switche Pointere til øvre og nedre grænser af hukommelse krævet for processen En list af åbne filer af processen Prioriteten af processerne Status af alle I/O enheder krævet af processen Ved hvert job skifte, skal processoren på en eller anden måde også hente disse informationer frem

Performance parametre for planlæggere Bruger orienterede parametre Turnaround tid: Tid mellem job instantiering og færddiggørelse Response tid: Tid fra en forespørgsel er sendt, til et svar er givet Deadlines: Antallet af deadlines der bliver mødt (bør være så høj som muligt, evt. udtrykt som antal nåede deadlines ud af antal deadlines eller jobs) Forudsigelighed: Et givet job skal bruge ca. samme udførselstid uanset hvor stor belastning der er på systemet -> jitter

Performance metrics for schedulers System orienterede parametre Throughput: Mængden af jobs der bliver færdige per tidsenhed Processor udnyttelse: Procentandelen af tid processoren er optaget af at udføre et job Fairness: Uden bruger indflydelse, bør jobs behandles ens, og have lige lang CPU tid; job tid versus gennemsnitlig job tid bør være ens Prioritetsopfølgelse: Prioriterede jobs bør have mere CPU tid; job tid versus gennemsnitlig job tid bør være større end lavere prioriterede jobs Balance mellem resourcer: Planlæggeren bør holde forskellige resourcer i balanceret brug (f.eks. ved multiprocessorer holde alle processorer rimelig balancerede i brug)

Basalt job eksekvering - enkelt processor system Start program CPU Exit program Preemption Blocked queue w = time spent in system, including waiting and executing e = time spent in execution s = total service time required by the task, including e.

Hændelses differencerings kø enkelt processor Start program CPU Exit program Preemption Blocked queue Event 1 queue Event n queue w = time spent in system, including waiting and executing e = time spent in execution s = total service time required by the task, including e.

Prioritetsbaserede kø systemer single processor RQ-0 CPU Exit program RQ-1 Start program RQ-n Blocked queue Preemption w = time spent in system, including waiting and executing e = time spent in execution s = total service time required by the task, including e.

Basalt job eksekvering og livscyklus multi processor CPU Start program CPU Exit program CPU Preemption Ikke blot et spørgsmål om at have jobs kørende på forskellige CPU er Inter proces synkronisering er svært Hukommelsesstyring er svært Overbelastning og uens belastning kan forekomme Et sted skal det besluttet hvilken CPU jobbet skal afvikles på

Nonpreemptive planlægning En planlægningsdisciplin er non-preemptive hvis først en proces er blevet tildelt en CPU, så kan den ikke tages væk fra CPU en Følgende er karakteriserende ved non-preemptive planlæggere Korte jobs er sat til at vente på længere jobs, men den gennemsnitlige behandling af jobs er fair Response tider er mere forudsigelige fordi indkommende høj prioritetsjobs ikke kan udskifte ventende jobs En planlægger eksekverer jobs i de følgende to situationer Når et job skifter fra en løbende tilstand til en ventende tilstand Når et job terminerer

Preemptive planlægning En planlægningsdisciplin er pre-emptive hvis først et job er blevet tildelt en CPU, så kan den flyttes Denne strategi tillader jobs der er logisk kørbare at blive midlertidig suspenderet i en såkaldt pre-emptive planlægning, og er en kontrast til kør indtil færdig metoden Round Robin planlægninsdisciplinen er pre-emptiv (for hvert tidsstykke) og derfor er den effektiv i et tidsdelt miljø der skal kunne garantere rimelige response tider til interaktive brugere.

First-Come-First-Served (FC-FS) planlægger #Tasks Task 4 Task 3 Task 2 Task 1 Effektivt Time Simpel politik: First task der ankommer i buffer, bliver først serviceret Normaliseret round-trip tid: t η = queue + t serving serving 1 FC-FS er normalt ikke nogen god job planlægger, da den typisk favoriserer processor bundne opgaver t

Round robin planlægger #Tasks Task 4 Task 3 Task 2 Task 1 Effektivt Time Fair tilgang da den tillader forskellige jobs et minimum af CPU tid Processor bundne opgaver har en tendens til at få mere CPU tid end andre opgaver der f.eks. skal vente på I/O hændelser Udvælgelse af eksekverings tider er ikke nødvendigvis trivielt Hvis valgt for kort, bliver RR metoden ineffektive pga. alt for mange proces context skift per tidsenhed Hvis valg for høj, risikerer man at opgaverne får høj response tid

Mindste opgave næste opgave - planlægger #Tasks Task 4 Task 3 Task 2 Task 1 Effektivt Time En non-preemptive metode Eksekverer de hurtige opgaver i en kø, før de længerevarende opgaver Leder til uforudsigelige response tider Kræver job udvikleren giver et estimat af eksekveringstiden, ellers må kernen understøtte løbende estimering af eksekveringstider Følsom overfor fejl/bugs/program typer som While(true);

Mindste tid tilbage - planlægger #Tasks Task 4 Task 3 Task 2 Task 1 Effektivt Time En pre-emptive version af den korteste opgave planlægger Så snart mindre opgaver ankommer i køen, gives disse prioritet Giver generelt en bedre turnaround time ydelse i forhold til den korteste opgave planlægger

Højest response forhold næste - planlægger En non-preemptive disciplin Prioritet bestemmes af den estimerede eksekveringstid, og den tid opgaven allerede har haft ventende på CPU tilgang tqueue + tˆ execution R = = 1+ tˆ execution queue execution Når en opgave er slut, eller blokeret, er opgaven med højest rankering R givet tilgang til CPU en Favoriserer små opgaver, men sikrer på samme tid at opgaver ikke venter ekstremt lang tid, og dermed leder til relativt lavere response tider for alle opgaver t tˆ

Feedback planlægger Start program RQ-0 CPU Exit program RQ-1 CPU Exit program RQ-n CPU Exit program I stedet for at estimere den tilbageværende service tid, er fokus på den allerede spenderede eksekveringstid Efterhånden som opgaver kræver forøget processeringstid, bliver de sat i lavere prioritetskøer

Kombinationer af de forhenværende metoder Er muligt med f.eks. FC-FS med Round Robin eller andre kombinationer Giver dog forøget kompleksitet der er uønsket Betragt kompleksitet af implementering af en metode versus den opnåede fleksibilitet og muligheder Forøget kompleksitet af en planlægningsalgoritme, leder til Forøget kode Højere sandsynlighed for fejl Højst sandsynligvis også højere context skift tid Tiden for at skifte opgave, context skift, bør holdes på et minimum, og ikke være mere end 5-10% af den samlede eksekveringstid

Realtids planlægning To typer af planlægningskrav Blød realtidskrav Er karakteriseret ved Det er ikke kritisk at møde en deadline, men ønskværdig Det giver mening at fortsætte eksekvering, selvom deadlines ikke er mødt Eksempel Bruger programmer som Power Point Log system Hård realtidskrav Er karakteriseret ved Det er absolut kritisk at en opgave nås til dens deadline Hvis en deadline ikke er overholdt, kan der ske fatale fejl, og det giver ingen mening at fortsætte eksekvering Eksempel Kontrol algoritmer for f.eks. Satellite retnings kontrol, atomkraftværk, robotter, Bilers bremsesystemer.

Karakteristika ved realtids OS Deterministiske Operationer kan udføres på forudsete tider eller med forudsete tidsinterval Ydelse i form at OS s evne til at minimisere jitter og delay i eksekvering af periodiske og tidskritiske operationer Svært at opnå i et multi processor system Respons evne Evnen for et OS til at instantiere en Interrupt Håndteringssmekasnisme Evnen til at foretage hurtige proces skifte (context skift) Udfordringer er hovedsagligt fokuseret omkring indlejrede interrupt og interrupt håndteringer

Karakteristika ved realtids OS Bruger kontrol For realtids OS er det en vigtig feature at kunne tillade brugere (her tænkes der applikationsudviklere) at have god kontrol over nøjagtigheden af opgave prioritering Fokus er på evnen til at Sætte opgave prioritet niveau (inkl. Hård/blød realtidskrav) Kontrol af interupts/atomiske operationer Politikker til at håndtere opgaver med ens prioritet Stabilitet og sikkerhed For realtidsapplikationer, er det absolut kritisk (for nogle mere end andre) at opgaverne bliver eksekveret Redundans på multikerne processorer, eller systemer kan være løsninger, men introducerer yderligere kompleksitet

Forskellige strategier ved realtids planlægning Request for RT operation Schedule RT activity on next time slice Clock tick Task 1 Task 2 Task n RT-Task A) Round Robin preemptive scheduler Request for RT operation Task 1 RT-Task Task 2 b) Priority driven nonpreemptive FCFS scheduler

Forskellige strategier ved realtids planlægning Request for RT operation Task 1 RT-Task Task 1 Task 2 c) Priority driven nonpreemptive FCFS scheduler, with deterministic preemption points Request for RT operation Task 1 RT-Task Task 1 Task 2 d) Priority driven nonpreemptive FCFS scheduler, with imidiate preemption points

Eksempel: RealTime Linux (RT-Linux) User space, Lowest priority... User app User app User app User app Kernel Space Low priority RT task Linux kernel Kernel modules in RT-Linux space RT Task RT Task RT Task RT Task RT-Linux kernel Hardware platform FIFO pipes or shared memory (controlled by the RT-Linux kernel) can be used for communication between RT Warning: a high priority RT Task should always at some time release CPU to other tasks!!!

Generelt for realtids kerner Evne til hurtige opgave skift Små i kode størrelse (især for indlejrede systemer) Evne til at svare hurtigt på eksterne interrupts (HW/SW) Multitasking med interproces kommunikationsmuligheder såsom semaforer, signaler og hændelser (events) Brug af speciel sekventielle filer, der kan akkumulere data ved hurtige hastigheder Pre-emptive planlægning baseret på prioritet Minimering af interval hvorimellem interrupts er afbrudt Primitiver til at udsætte opgaver i et givet stykke tid, og til at ændre tilstande på opgaver mellem f.eks. pause/fortsætte Specielle alarmer og time-outs (f.eks. watch dog timers)

Beskyttelse af resourcer Beskyttelse af resourcer er kritisk, men hvordan gøres dette fair? There is a group of philosophers (usually 5) who eat together at a round table. There are forks placed between the philosophers. Philosophers spend their time either thinking or eating. In order to eat, a philosopher must pick up exactly two forks, one on his immediate left, and the other on his immediate right. When he is done eating, he will put his forks down so that his neighbors may use them, and he thinks again. Diskution: Ville det hjælpe med en tjener? Vil en beskidt gaffel hjælpe og hvordan? Philosophers dining problem

Race condition Betragt to jobs; A, B der hver udfører flg. 1. Read X 2. Do X=X+1 3. Write X back Hvis eksekveret sekventielt, vil X blive 2 når A og B er færdige Task A Task B Integer X Read X X = X+1 Write X=1 Read X X = X+1 Write X=2 I et pseudo parrallelt miljø, kan X blive 1!! Time Task A Read X X = X+1 Write X=1 Time Task B Read X X = X+1 Write X=1

Deadlocks Når to tog nærmer sig hinanden ved et kryds, skal begge stoppe og ingen skal køre videre før at det andet tog har passeret

Hændelser og inter proces kommunikation #Tasks Task 4 Task 3 Task 2 Task 1 Processer har potentielt behov for at Kommunikere med hinanden, f.eks. Udveksle data objekter/informationer Vente på hinanden, f.eks. Ved beregning af et resultat, eller eksterne hændelser (HW/SW interrupts) Benytte samme ressourcer, såsom Diskette drev/filsystem Hukommelse Keyboard Time

Job synkronisering Typiske operationer som tråde/processer kan anvende Semaphores og/eller mutexes: Til at undgå inkonsistens mellem resourcer og data Signaler: Dedikerede beskeder anvendt til at indikere andre jobs at de skal udføre et eller andet, f.eks. Stop eksekvering, pause, vent,... Hændelse (event): At notificere et job om at et eller andet er sket, f.eks. Jeg har beregnet X, Y har forespurgt om Z IEEE definerer en standard for job interaktion (IEEE Std 1003.1, Posix), se også online på http://standards.ieee.org/regauth/posix/

Multiprocessor planlægning I nogle systemer er der mere end en CPU til rådighed for at eksekvere en applikation Klasser af multiprocessor systemer Løst koblet eller distribuerede multiprocessors: En samling af relativt autonome processorer med hver deres egen hukommelse og I/O Funktionelt specialiserede processorer: I/O processorer til f.eks. Grafik, lyd, filsystem m.f. Tæt koblet multiprocessors: Et sæt af processorer der deler en fælles hukommelse og som er under kontrol af et OS

Distribuering af jobs Job deling: De enkelte opgaver er ikke associerede til en enkelt processor. En global kø af eksekverbare jobs er vedligehold, og hver processor vælger og eksekverer et job fra denne kø. Gruppe planlægning: Et sæt af relaterede jobs, f.eks. Tæt interagerende processer planlægges at køre på samme processor på samme tid, på et ettil-et basis Dedikeret processor tilvalg: Hvert proces er allokeret et antal af processorer lig med antallaet af tråde det genererer. Hver tråd køres på en seperat processor. Dynamisk planlægning: Virker på samme måde som den dedikerede processor tilvalg, men eftersom antallet af tråde der generes af en proces kan variere over tid, er tråde tildelt processor dynamisk

Opgaver Diskuter anvendelsen af job planlægning i jeres projekt Hvilke planlægningsmetoder kan være anvendelige for jeres projekt? Hvordan skal de kommunikere med hinanden? Er der flere processorer involveret, eventuelt over netværk? Hvordan håndterer man distribuerede opgaver efter de viste principper? Tidskrav Hvad er jeres tidskrav? Hvordan finder i frem til dem? Hvad er konsekvenser for i ikke kan nå jeres opgaver til tiden?

Opgaver Projekt Diskussion (15min): Diskuter potential anvendelse af grafer i jeres projekt Hvad type graf kan være anvendelig (direkte/indirekte) og hvad form for kant-markering kan være brugbar? Hvilken type job/algoritme skal i bruge i jeres projekt for at arbejde med disse grafer? Hvor mange dronninger kan man sætte sikker på et 4x4 felt stort skakbræt? 8x8 felt stort skakbræt? 16x16 felt stort skakbræt? Hvordan vil det være hvis man puttede f.eks. En bonde ind på brættet? Hvordan vil det være hvis man tog en anden brik, f.eks. Et tårn eller en springer?