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!