Lecture Notes for Concurrent Programming

23 July 2002 - Immutable Class Instances

Immutable Class Instances

• Immutability

• Immutable Classes

  • Final Fields

  • Construction

• Functional Programming

  • Mutating Immutable Data

Immutability

• Instances that don't change can't cause interference.

  • No write conflicts, no time-dependent behavior.

• Instances without state can't change.

  • There's nothing to change.

  • Not as dumb as it sounds (functional programming).

• Instances with unchanging state can't change (duh).

  • Providing unchanging state can be tricky.

    • Optimization pressures; initialization problems.

• Immutable instances also promote sharing.

  • Large, read-only data structures.

  • Boss-worker image processing algorithms.

Immutable Classes

• Java has a lot of immutable classes.

  • java.awt.Color, java.math.BigDecimal, java.lang.String.

• Immutable classes have (surprize!) no mutating methods.

  • Except for initialization, not even hidden mutations are allowed.

• Roll-you-own enumeration is the canonical immutable-class example.

• Mutable class instances can be frozen into immutable instances.

  • Checkpointing, for example.

Immutable Classes and Final Fields

• Public fields in immutable classes.

  • Why not make it public?

    • It's unchanging, and method calls are expensive.

  • This is dangerous thinking.

    • Without care, values can be changed.

    • Breaking encapsulation may come back to bite.

• Do not be seduced by the final keyword.

  • Only the final field itself is unchanging.

  • Unchanging references can change instances.

  • Similar to const T * vs. T * const in C++.

• Everything reachable from a final field must be immutable.

  • Final fields of basic type are fine.

  • Final fields of immutable class instances are fine.

  • Final fields of mutable classes instances don't work.

Final Field Examples - The Good

• Good: basic type values.

  class fraction()
    public final long numerator, denominator
  

  • Legal: System.out.println(f.numerator)

  • Illegal: f.numerator = 3
f.numerator is final.

  • Atomicity is not the issue here.

• Good: references to immutable classes.

  class name()
    public final String firstName, lastName
  

  • Legal: System.out.println(n.firstName)

  • Illegal:
    n.firstName[0] = toUpper(n.firstName[0])
Strings are immutable.

• All of this still breaks encapsulation.

Final Field Examples - The Bad

• Bad: references to mutable classes

  class roster()
    public final Student classRoster[]
  

  • Legal: System.out.println(cs598.classRoster[0])

  • Legal: cs598.classRoster[0] = null

    The array reference is unchanging; the array is not.

    Neither are the array elements.

  • Here comes interference.

Construction

• No changes after initialization.

• Initialization can cause trouble.

• Prevent access to unitialized final fields

  • Hide this during initialization.

  • Watch the (virtual) method calls.

• Lengthly initializations may increase latency.

  • The shared image example.

  • Eat the latency or re-introduce synchronization.

• Don't forget equal() and HashCode() contracts.

  • Instances that get compared or stored may need them.

  • With a perfect hash, equal() is the same as ==.

Functional Programming

• Stateless objects are necessarily immutable.

• Functions are stateless objects.

  • Input comes in via the argument list.

  • Output comes goes out via the function return.

  • Nothing sticks around between.

• Functions must be side-effect free.

  • All output must be via the function return.

    • Via arguments too, with care (no aliases).

  • Unfortunately, I-O is an important side-effect.

• Functional programming is an important concurrency approach.

  • Evaluate argument expressions in parallel.

    • f(g(), h()) or i = f() + g()

• OOL aren't conductive to functional programming.

  • Functions are secondary, data are cumbersome.

Mutating Immutable Data

• How to mutate immutable data structures?

  • Build the new one using the old ones.

    String replace(
      String str, String old, String new)
    
      int i = find(str, old)
    
      return 
        str[0..i] + 
        new + 
        str[i+old.length()-1..str.length()]
    

• This can get inefficient.

  • Witness String vs. StringBuffer.

• Lisp programmers are familiar with this approach.

• Memory management makes C++ programmers afraid.

  • Don't be afraid, Java will help you (heh, heh).

Points to Remember

• Immutable data has no interference problems.

  • Easily shared; unsynchronized, safe concurrent access.

• Watch out for final.

  • Understand T * const vs. const T *.

• Initialization takes some care.

  • Particularly for immutable subclasses.

• Functional programming is an immutable-programming model.

  • It may be worth the oo-overhead to implement.

This page last modified on 30 July 2002.