Skrive/kodelab

Dato:	30 Apr 2014
Varighed:	8 timer

Status

2. Koden for IO skal skrives om så den passer 100% med bogen og interrupt-implementationen.
3. Implementeringerne skal have nye navne.
4. Snak med vejleder
5. Kontakt 'Henrik' ift. kode.
1. Gennemlæsning og forbered første del af rapport på (peer) review. Inkluderer bilag.
?. Overbliksbillede over leJOS til EV3.
?. Snak med anden speciale-gruppe om gensidig gennemlæsning/retning af rapport.
?. Cykeltur og d-vitamin ordnet!

Mål

Gennemgå hele rapporten, samt indkøb af props til review (overstregnings-tusch).
Gennemgå og begynd arbejde på kode.

Arbejde

Udskrivning af rapport var problematisk. Det er nu ordnet, nogenlunde. Havde glemt at overveje at billeder stadig skal overføres til printerserveren, hvilket med den nuværrende opløsning tager... lang tid.
Indkøb af test-materiale (overstregningstusher) er oversået og testpersoner er inddraget til første gennemlæsning af "Grundlæggende" del af rapporten.

Snak med Ole var rigtig fin. Han bekræftede mine tanker ift. io-implementering og fortalte at jeg burde kunne finde dokumentation for min fortolkning af flere forskellige resourcer's samtidig arbitrering, i bogen. Han sagde det var i kapitel 9, men ... det tror jeg ikke. Må følge op på dette!

Koden skrevet delvist om. Den er nu nogenlunde "ens" læsbart for de 2 implementeringer, og begge implementeringer har de samme "adfærd" (Exit er måske ikke en adfærd?). Et par af adfærdene skal muligvis deles op i 2.

Stadig intet svar inde på leJOS forum ift. det overbliksbillede :/ Det kan være at jeg ender med at skulle stykke det sammen fra bunden, uden hjælp/indsigt... *suk*

Skrivelab

Dato:	29 Apr 2014
Varighed:	4 timer

Status

3. Koden for IO skal skrives om så den passer 100% med bogen og interrupt-implementationen.
4. Implementeringerne skal have nye navne.
5. Snak med vejleder
6. Kontakt 'Henrik' ift. kode.
2. Gennemlæsning af første del af rapporten.
1. Motivation-afsnittet
?. Part-inddelingerne mangler introduktion/indledning.
?. Overbliksbillede over leJOS til EV3.
?. Snak med anden speciale-gruppe om gensidig gennemlæsning/retning af rapport.

Mål

Fortsæt Introduktion/motivation.

Skrivning

Motivations-afsnit "afsluttet". Mangler resultat-sektionen (åbenlyst), men resten er ret fint udformet allerede.
Part-inddelingerne har en kort, upræcis "indledning", som passer fint nok indtil videre. Står også nogenlunde på siden (og kan nu nemt rettes til).
Gennemlæsning og tilpasning af første del af rapporten afsluttet. Den er nu klar til "friske øjne". Snak med den anden speciale-gruppe...

Tidligt "fri" for at fejre første del. Cykeltur er nok smart, så d-vitamin ikke går helt i bund...

Skrivelab

Dato:	28 Apr 2014
Varighed:	3 timer

Status

2. Koden for IO skal skrives om så den passer 100% med bogen og interrupt-implementationen.
3. Implementeringerne skal have nye navne.
4. Snak med vejleder
5. Kontakt 'Henrik' ift. kode.
2. Motivation-afsnittet
1. Ret resten af det grundlæggende i rapporten (forside osv)
?. Part-inddelingerne mangler introduktion/indledning.
?. Overbliksbillede over leJOS til EV3.

Mål

Følg op på overblinksbillede af leJOS på webboard.

Gennemlæs og "ret" rapport; een gang til.
Fortsæt Introduktion/motivation.
Ret i evt. en smule i makroer. Burde være minimalt arbejde

Skrivning

Webboarded er tavst... Håber der kommer et svar, men havde forventet noget her over en weekend.
Rapport-opdelingen (\part) rettet til, så en kort introduktion kan stå "pænt" til højre i toside-layoutet.
Motivations-afsnit påbegyndt; kraftigt inspireret fra opsætning fra tidligere specialer.

Skrivelab

Dato:	25 Apr 2014
Varighed:	7 timer

Status

2. Koden for IO skal skrives om så den passer 100% med bogen og interrupt-implementationen.
3. Implementeringerne skal have nye navne.
4. Snak med vejleder
5. Kontakt 'Henrik' ift. kode.
2. Motivation-afsnittet
1. Ret resten af det grundlæggende i rapporten (forside osv)

Mål

Gennemlæs og "ret" rapport; forståelse og mangler.
Begynd på Introduktion/motivation.
Send email/skriv på webboard for leJOS ang. overbliksbillede over leJOS til EV3.

Skrivning

Post skrevet på webboarded, så det forhåbentligt kan besvares i løbet af weekenden.
Io og interrupt skrevet "færdigt". Klar til friske øjne.
Grundlæggende del mangler en introduktion og hver "del" af rapporten mangler måske en lille kort beskrivelse i højre side? Ja...
EV3-afsnit mangler et overblikbillede i højre side. Afvent svar på webboard.

Skrivelab

Dato:	22 Apr 2014
Varighed:	7 timer

Status

2. Koden for IO skal skrives om så den passer 100% med bogen og interrupt-implementationen.
3. Implementeringerne skal have nye navne.
4. Snak med vejleder
5. Kontakt 'Henrik' ift. kode.
?. Motivation-afsnittet
1. Gennemlæs og ret forståelses-problmer i rapporten.

Mål

Gennemlæs og "ret" rapport; forståelse og mangler.

Forklaring af dagen

Hjemmearbejde, så en pakke kan modtages. Sandsynligvis mindre produktivt : /

Pga. hjemmearbejdet bliver status-listen ignoreret en smule. Der er kun ordentligt mulighed for at skrive på rapporten hjemmefra - dvs. kode-skrivning er ikke optimalt, og alle punkter der kræver fysisk fremmøde er ligeledes udelukket.

Skrivningen

Fik gennemrettet og tilpasset store dele af den "grundlæggende" del af rapporten. Kode-stykkerne var besværlige ift. at konvertere html-tags til bold...

Mangler rettelser/skrivning på io- & interrupt-implementationerne, men afsnittet om adfærd generelt er totalt skrevet om (og er blevet nogenlunde godt, efterhånden).

Skrivelab

Dato:	15 Apr 2014
Varighed:	7 timer

Status

1. Kodeafsnittene skal skrives/skrives om.
2. Skal koden skrives om? Undersøg hvad der skal laves om og skriv det om.
3. Implementeringerne skal have nye navne.
4. Snak med vejleder
5. Kontakt 'Henrik' ift. kode.

Mål

Kodeafsnit skal skrives om i dag.

Skrivningen

Tilføjelser og udbedringer af formålet med kodeafsnitene lavet. Mangler stadig ting, men de kan udbedres senere..

Selve Eksperiment-delen af rapporten er efterhånden klar til at blive påbegyndt. Yay!

Tænk en smule mere over hvordan "motivationen" skal skrives... Den skal på statuslisten for i morgen.

Desværre skal koden for IO skrives en "smule" om, så den tydeligt følger kode-stumperne fra bogen (der må gerne være genkendelse fra kode til kode, hvis muligt)...

Rapporten manger en gennemlæsning/-retning af første del...

Computerproblemer og læsning

Dato:	14 Apr 2014
Varighed:	6 timer

Status

3. Kodeafsnittene skal skrives/skrives om.
5. Refactoring af kode så den kan bruges i rapporten mangler.
6. Implementeringerne skal have nye navne.
4. Kontakt 'Henrik' ift. kode.
2. Læse om concurrency.
1. Opsætte ny computer

Mål

Læse Java Concurrency in Practice færdig, samt få ny PC (gamle døde helt) op og køre...

Opsætning af computer... igen

Denne gang burde computeren holde sig oven vande lidt længere... Grunden til alt denne spild-tid med hjemme-computer er, at min arbejdscomputer's skærm er... dårlig. Til læsning af store mængder (f.eks. rapport og de forholdsvis mange artiker) er det et must med en skærm der ikke dræber øjnene...

TexLive tager frygtelig lang tid at hente...

Tanker om Java-concurrency (fortsat)

Chapter 12-15: Ignorer mm. specifik ting skal bruges derfra...

Chapter 16: Super afsnit (og kort!), der fint beskriver mit problem... Særligt en opsummering som s. 225 havde været rart dengang jeg skulle lære om emnet første gang (ikke at jeg tror at amoeller's side var tiltænkt som komplet gennemgang af emnet).

Lazy: s. 229 -> fixme, maybe

Kode- og læselab

Dato:	11 Apr 2014
Varighed:	6 timer

Status

2. Kodeafsnittene skal skrives/skrives om.
4. Refactoring af kode så den kan bruges i rapporten mangler.
5. Implementeringerne skal have nye navne.
3. Kontakt 'Henrik' ift. kode.
1. Læse om concurrency.

Mål

Teste/implementere korrekt flertrådet adfærd i koden, for at se om det løser problemerne.

Læse Java Concurrency in Practice færdig.

Koden

IO-implementations-koden er nu skrevet om så sensor-data kun bliver opdateret eet sted (af Arbitratoren i slutningen af hver iteration) samt at denne data tilgåes på en non-blocking, thread-safe måde. Desværre læser disse forholdsregler ikke mit problem, omend jeg nu har indsnævret problemet til præcis hvad der går galt.

Herunder ses en graf der markerer hver gang en Adfærd eller Arbiteren tilgåes. Derudover er der en række Arbitrator-### markeret. Disse indikerer hvornår ### er færdig med at blive opdateret for Arbiteren.

Ved nøjere granskning af grafen er det for mig tydeligt at problemet er ift. opdatering af IR-værdierne. Der er et synligt stop imellem Ultrasonic-sensoren og IR-sensorens timestamp for færdiggørelse.

Problemet ligger sandsynligvis i at IR-sensoren laver 5 foresprøgelser sammenlignet med 1 for hver af de andre sensore. Ved nærmere granskning af koden er det dog også tydeligt at der er tale om 5 sekventielle "I2C register"-foresprøgelser.

Jeg vil tro at grunden til at dette er et problem i et flere-trådet miljø, men ikke i et enkelt-trådet må være, at OS nedprioriterer leveringen af dataen til IO-tråden, sammenlignet med alle de andre tråde (Adfærd) der er CPU-krævende. I tilfældet hvor der kun er 1 worker-tråd, vil det ikke betyde noget markant, hvis tråden i en periode, af OS, bliver markeret som IO-baseret.

Min antagelse er baseret på de ca. 3 sekunders "wait" som IR foretager i starten (inden nogen adfærd eller arbiteren's arbejde er startet). Disse 3 sekunder bliver næsten nød til at være et (5) IO-wait, da det eneste der sker er at 5 værdier bliver hentet fra en sensor og gemt i lokale fields.

Problemet er uanset årsagen, dybt forankret i hvordan leJOS er opbygget, og det vil ikke være muligt at løse problemet uden at skrive en mærkbar del af leJOS-frameworket om - altså en opgave der ikke har noget af gøre med dette speciale (selvom det er en interessant udfordring at løse dette problem på en fornuftigt og skalerbar måde...). 

Læselab

Dato:	10 Apr 2014
Varighed:	7 timer

Status

2. Kodeafsnittene skal skrives/skrives om.
4. Refactoring af kode så den kan bruges i rapporten mangler.
5. Implementeringerne skal have nye navne.
3. Kontakt 'Henrik' ift. kode.
1. Læse om concurrency.

Mål

Læse Concurrency: State Models & Java Programs, 2nd Edition (pensum fra Concurrency kurset) samt Java Concurrency in Practice (bedre anmeldt bog om netop java).

Concurrency: State Models & Java Programs, 2nd Edition (CSMJ)

Bogen har en glimrende gennemgang af hvad concurrency går ud på: At håndtere samtidig tilgang til delte værdier.Dette gøres primært vha. FSP (Finite State Programs), med en kodestump java bagefter til at illustrere hvordan det gennemgåede vil se ud i java.

Problemet er dog, at en række "moderne" (læs: moderne i 2006) java-specifikke ting ikke bliver gennemgået i bogens pensum: 

1. Concurrency og JIT
2. Java's concurrency klasser

Disse 2 emner bliver ikke berørt i kurset Concurrency, hvilket har skabt mit problem. Jeg er klar over at bogen faktisk nævner at alle delte værdier skal beskyttes, men samtidig er in alle eksempler på "delte værdier" af typen (for read-write synkronizering):
T1: read-update-write (problemer hvis context switch sker efter read og inden write)
T2: read

mit eksempel:
T1: write (ignorer tidligere værdier, ingen problemer ift. concurrency... eller?*)
T2: read

Jeg mener at der ud fra bogens eksempler er god grund til at tro at T2 altid får een af de nyeste værdier (jeg er ligeglad med om det er helt den nyeste). Alle writes er atomic, så jeg risikerer ikke ugyldige reads (eller?*). Jeg kommer mere ind på hvad der faktisk sker i senere her på bloggen.

Java Concurrency in Practice (JCIP)

Begge punkter med eller?* er desværre ikke korrekte. De er begge baseret på følgende antagelse:

• Read/write er atomic, så hvert read får senest skrevne værdi.

boolean asleep;

   ...

   while (!asleep)

      countSomeSheep();

Dette eksempel er fra bogen JCIP (næsten), hvor der forklares at der ved flertråede programmer opstår et problem netop her. JIT må nemlig optimere tilgangen af asleep-variablen, så den er cached lokalt i den tråd (T1) der bruger den. Dette betyder at selvom en anden tråd (T2) opdaterer variablen (uanset hvordan dette er struktureret), så vil T1 aldrig læse den nye værdi.
Læsningen er at benytte syncronization eller at angive asleep som volatile.

Der er faktisk en henvisning til https://cs.au.dk/~amoeller/dConc/jsr-133-faq.html, på mit gamle concurrency-kursus. Dengang jeg læste denne del troede jeg og min studiegruppe at vi forstod det der var centralt på siden, men jeg kan nu se at vores forståelse af volatile (samt hvordan JMM er opbygget) var mangelfuld. Faktum er at netop eksempler som mit er grunden til at der findes volatile-keyworded i java:

• Writes to the variable do not depend on its current value, or you can ensure that only a single thread ever updates the value; 
• The variable does not participate in invariants with other state variables; and 
• Locking is not required for any other reason while the variable is being accessed. 

Denne definition passer på mit eksempel.

Tanker om Java-concurrency

Race condition

Syncronization s6

Safety s6

Liveness s6

Performance s6

Context-switch s7

Shared mutable objects s11

Thread safety s11

Visibility s 23

Encapsulation & perserving invariants

Thread confinement

Immutable objects are always thread safe. -> More final

Barriers: solution to problem with IO-imp?

Timer+TimeTask: solution to problem with IO-imp?

Chapter 8: Thread Pool Size

Chapter 11: Golden stuff!

Skrivelab

Dato:	9 Apr 2014
Varighed:	8 timer

Status

1. Adfærdshierakiet -> + kodestumper
2. Kodeafsnittene skal skrives/skrives om.
4. Refactoring af kode så den kan bruges i rapporten mangler.
5. Implementeringerne skal have nye navne.
3. Kontakt 'Henrik' ift. kode.

Mål

Skriv om hver adfærd, så det kan bruges i kapitlet om adfærdshieraki.
Skriv om hver implementering, kortfattet.

Skriveprocess

Adfærdshierakiet -> + kodestumper blev nogenlunde færdigt.

Kodeafsnittene endte med at mangle noget om concurrency. Dette "noget" har jeg ikke referencer til. Endnu. Tilbage til læse-delen, så jeg kan henvise min erindring om hvad concurrency er, til en bog. Måske "Java Concurrency in Practice"?

Refactoring af projektet

Dato:	4 Apr 2014
Varighed:	7 timer

Status

4. Adfærdshierakiet -> + kodestumper
5. Kodeafsnittene skal skrives/skrives om.
3. Refactoring af kode så den kan bruges i rapporten mangler.
6. Implementeringerne skal have nye navne.
1. Tavle taget i brug til projektstyrring.
2. Kontakt 'Henrik' ift. kode.

Mål

Kontakt Henrik.
Færdigør arbejdet med at gennemarbejde koden.
Skriv om hver adfærd, så det kan bruges i kapitlet om adfærdshieraki.

Henrik

Jeg besluttede at vente til på mandag med at finde Henrik, da der er 3 forskellige personer på etagen med det navn, og de er allesammen travle.

Koden

Indtil en grundig feedback på den kode jeg har, er der ikke meget større værdi at tilføje projektet ved at omskrive koden yderlig. Har i stedet opsat macroer til "generisk" kode-udpluk til rapporten, så koden-eksemplerne (næsten) dynamisk opdateres med nyeste indhold fra kildekoden.

Omstrukturering af projektstyrring

Besluttede at droppe ideen om at poste billeder af min fysiske tavle som status/mål/slut for dagen, da det vil have en ret negativ effekt på hvordan bloggen ser ud i udskrevet udgave (formålet med denne blog).

Der er i stedet en kopi nedskrevet på bloggen for læsbarhedens skyld.

Refactoring af kode

Dato:	3 Apr 2014
Varighed:	8 timer

Status

Adfærdshierakiet skal skrives om, så det illustrere robottens forskellige adfærd.
Kodeafsnittene skal skrives/skrives om.
Implementeringerne skal have nye navne.
Egen kode skal refactoreres så den kan bruges til omskrivningen af kapitlet om robottens adfærd.

Mål

Gennemarbejd kode med fokus på opdeling og læsbarhed.

Kodegennemgang

Et nyt forsøg på at gøre adfærd samt deres funktion simpelt tilgængelig og fuldstændigt adskilt fra kontrolmekanismer, synkronisering ol.

Refleksion

Dato:	2 Apr 2014
Varighed:	8 timer

Status

Adfærdshierakiet skal skrives om, så det illustrere robottens forskellige adfærd.
Kodeafsnittene skal skrives/skrives om.
Implementeringerne skal have nye navne.
Egen kode skal refactoreres så den kan bruges til omskrivningen af kapitlet om robottens adfærd.
Formål med sammenligning af implementationerne ift. problemformulering skal gennemarbejdes.

Mål

Gennemarbejd problemformulering og kom på afstand af kode/blog.

Dag uden computer

Dagens arbejde gik med at overveje/reflektere over hvordan rapporten skal strikkes sammen, hvordan arbejdet rapporten har forløbet, samt problemformuleringen.

1. Projektets kode skal have fokus på "læsbarhed" ift. hvad der sker med robotten.
2. Status/mål/resultat pr. dag skal laves lidt om: Brug af tavle skal udvides.
3. Der skal stoppes op med jævne mellemrum for at få et overblik, jf. denne dag.

Refactoring af kode

Dato:	1 Apr 2014
Varighed:	7 timer

Status

Adfærdshierakiet skal skrives om, så det illustrere robottens forskellige adfærd.
Kodeafsnittene skal skrives/skrives om.
Implementeringerne skal have nye navne.
Egen kode skal refactoreres så den kan bruges til omskrivningen af kapitlet om robottens adfærd.

Mål

Gennemarbejd kode med fokus på opdeling og læsbarhed.

Kodegennemgang

Koden er nu opdelt således at hver adfærd har betingelsen for hvornår den's handling kan udføres adskilt fra selve adfærden. Ligeledes er der lavet små-ændringer der sikrer at selve adfærds-koden er minimeret betragteligt, samt gjort mere forståeligt.

Jeg har også kastet mig over at se på Ole's implementation ift. min egen. De er ikke så forskellige som først antaget, men jeg er alligevel begyndt at se på en udgave af Ole's implementation integreret i mit projekt. Det burde ikke være så besværligt, og så snart hans kode er final vil det tage omkring 1 dag.