-
Notifications
You must be signed in to change notification settings - Fork 21
Closed
Description
https://groups.google.com/forum/#!topic/scala-internals/P7WNVkJQdHk
We had several discussion previously about this during the Scala meeting.
I believe that we could solve the list issues by adding the @volatile
annotation to the head and tail vars.
Since those fields is only read afterwards, it should not drastically
affect performance, if at all - then again, would be useful to try to
compile the distribution with and without the @volatile in Lists.
Cheers,
Alex
- hide quoted text -
On 9/12/13 6:21 PM, Jason Zaugg wrote:
> A few recent threads [1] [2] have led me to learn a bit more about the
> JMM and consider how this applies to the standard library.
>
> Both of our poster-children for immutable data structures harbour some
> dirty little vars. The head and tail of our :: are vars, which allows
> ListBuffer to directly build a list in start-to-finish order, and
> Vector has a flag `dirty` that seems to be mutated during the first
> moments of its life before the reference is released.
>
> But, this means that if someone unsafely publishes `new ::("", Nil)`
> or `Vector(1)` to another thread, that thread could observe a
> inconsistent state (a null `::#hd`, or `Vector#dirty` still set to true.)
>
> The JMM makes stronger guarantees for final fields [3][4], this
> potential problem is specific to non-final fields, even ones that are
> assigned in the constructor.
>
> Given that the canonical example for the need for the JMM's special
> treatment of final fields is avoiding data races in j.l.String (its
> somewhat lonely poster child for immutability); what is our position
> on not being protected by the same guarantees for List and Vector?
>
> -jason
>
> [1]
> http://scala-programming-language.1934581.n4.nabble.com/Why-use-List-td2217742.html
> [2] https://groups.google.com/d/msg/scala-user/ORxWFIzRb2c/ZzsQ9fsmq40J
> [3] http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
> <http://www.cs.umd.edu/%7Epugh/java/memoryModel/jsr-133-faq.html>
> [4] 17.5 final Field Semantics
>