Scala val has to be guarded with synchronized for concurrent access?

Question

As I read, Scala immutable val doesn't get translated to Java final for various reasons. Does this mean that accessing a val from an other Thread must be guarded with synchronization in order to guarantee visibility?

Answer 1

the assignment to val itself is fine from a multi-threading point of view, because you have to assign val a value when you declare it and that value can't be changed in the future (so if you do a val s="hello", s is "hello" from its birth on: no thread will ever read another value). There are a couple of caveats, however:

1 - if you assign an instance of a mutable class to val, val by itself will not "protect" the internal state of the class from changing.

class Foo(s:String) { var thisIsMutable=s }
// you can then do this
val x = new Foo("hello")
x.thisIsMutable="goodbye"
// note that val guarantees that x is still the same instance of Foo
// reassigning x = new Foo("goodbye") would be illegal

2 - you (or one of your libraries...) can change a val via reflection. If this happens two threads could indeed read a different value for your val

import java.lang.reflect.Field
class Foo { val foo=true } // foo is immutable

object test {
  def main(args: Array[String]) {  
        val f = new Foo
        println("foo is " + f.foo) // "foo is true"

        val fld = f.getClass.getDeclaredField("foo")
        fld.setAccessible(true) 
        fld.setBoolean(f, false) 
        println("foo is " + f.foo) // "foo is false"
  }
}

Answer 2

As object members, once initialized, vals never change their values during the lifetime of the object. As such, their values are guaranteed to be visible to all threads provided that the reference to the object didn't escape in the constructor. And, in fact, they get Java final modifiers as illustrated below:

object Obj {
  val r = 1

  def foo {
    val a = 1
    def bar = a
    bar
  }
}

Using javap:

...
private final int r;
...

public void foo();
...
   0:   iconst_1
   1:   istore_1
   2:   aload_0
   3:   iload_1
   4:   invokespecial   #31; //Method bar$1:(I)I
   7:   pop
...
private final int bar$1(int);
...
   0:   iload_1
   1:   ireturn
...

As method locals, they are used only within the method, or they're being passed to a nested method or a closure as arguments (see lifted bar$1 above). A closure might be passed on to another thread, but it will only have a final field with the value of the local val. Therefore, they are visible from the point where they are created to all other threads and synchronization is not necessary.

Note that this says nothing about the object the val points to - it itself may be mutable and warrant synchronization.

In most cases the above cannot be violated via reflection - the Scala val member declaration actually generates a getter with the same name and a private field which the getter accesses. Trying to use reflection to modify the field will result in the NoSuchFieldException. The only way you could modify it is to add a specialized annotation to your class which will make the specialized fields protected, hence accessible to reflection. I cannot currently think of any other situation that could change something declared as val...