Java Threads and JMM

Question 1

Memory Model

Answer 1

Defines the necessary and sufficient conditions for knowing what writes to memory by other processors are visible to the currentt processor, and vice versa

Question 2

JMM

Answer 2

• Defines a partial-ordering (happens-before) on all actions within the program
• Defines the behaviour of volatile, synchronised etc.
• It shields the Java dev. from the differences between memory models across architectures.
• It does this for a specific platform by inserting memory barriers at the appropriate places for that platform, it thus ensure that everything is correctly synced

Question 3

Sequential vs Multithreaded Environments

Answer 3

Single
* The Java language specification requires the JVM to maintain within-thread as-if-serial semantics
* As long as the program has the same result as if it were executed in program order in a strictly sequential environment, out-of-order executions are permissible

Multi-threadd
* The illusions of sequantiality cannot be maintained without significant performance cose; i.e. a strong memory model, which ensures that all processors see exactly the same value for a given memory location at all times, is too expensive
* with a weaker memory model, a thrad might not see the most up-to-date value for a variable and memory actions in other threads can appear to happen out of order
* memory barriers are required to flush or invalidate the local processor cache to see writes made by other processors or make writes by this processor visible to others

Question 4

Happens before rules

Answer 4

• Program order rule
• Monitor lock rule
• Volatile variable rule
• Thread start tule
• Threat termination rule
• Interruption rule
• Finaliser Rule
• Transitivity

Question 5

Program order rule

Answer 5

that each action in a thread, happens before every action in that thread that
comes later in the program order

Question 6

Thread start rule

Answer 6

A call to Thread.start on a thread happens-before every action in the started thread

Question 7

Thread termination rule

Answer 7

Any action in a thread happens-before any other thread detects that thread has terminated, either by successfully returning from Thread.join or by Thread.isAlive resturning false

Question 8

Volatile variable rule

Answer 8

A write to a volatile filed happens before every subsequent read of that same field

Question 9

Finaliser rule

Answer 9

The end of a constructor for an object happens before the start of the finaliser for that object

Question 10

Final fields

Answer 10

• Once an object is constructed correctly the values assigned to the final field in the constructor will be visible to all other threads without synchronisation
• In addition, the visible values for any other object or array referenced by those final fields will be at least as up-to date as the final fields
• Constructed correctly
  
  • No reference to the object being constructed is allowed to escape during construction
  • A reference to the object being constructed should not be placed anywhere where another thread might be able to see it
    
    • e.g. not assigned to a static field or registered as a listener with any other object
    • These tasks should be done after the constructor completes, not in the constructor

Question 11

Static initialiser

Answer 11

• offers thread-safety guarantees
• Run by the JVM at class initialisation time
• The JVM acquires a lock during initialisation, which is acquired by each thread at least once to ensure that the class has been loaded
• Thus memory wrties made during static init. are automatically visible to all threads
• This applies only to the as-constructed state
• If the object is mutable, synchronisation is still required by both reads and writere fo make subsequent modification visible and avoid data corruption.