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...).