Mutable vs Immutable for parallel applications

Question

In the application I am writing, I need to write lots of base types, which will most likely be immutable. But I am wondering how mutable types compare in parallel applications to immutable ones.

You can use locks with mutable objects, right? How does it compare to other techniques used with immutable types in parallel applications?

You are at least away from using locks with immutable types, right?

Answer 1

Types

• Use immutable types as much as possible.
• Use thread-safe collections instead of explicit locks as much as possible.
• Only use mutable types when you have no other reasonable choice.

Threads

• Use thread pools as much as possible.
• Use endless loops when thread pools aren't possible.
• Manually start and stop threads as a last resort.

If you do have to use explicit locks, document them throughly. Especially when it comes to the order in which you lock objects. If you know that Foo objects are always locked before Bar objects and that Foo(key 100) is always locked before Foo(key = 200), you won't get deadlocks.

Answer 2

The key to writing parallelizable applications is to stay away from mutable shared state. Sharing mutable state between threads requires synchronization which typically entails some form of locking. Using immutable types can help ensure that you are not accidentally sharing state, by making it impossible to change the state of those objects. However, this is not a magic bullet, but simply a design choice. If the algorithm you are attempting to parallelize requires shared state, you are going to have to create some sort of synchronization.

Mutability does not affect locking.

Answer 3

When you use mutable types you are exposing yourself to Write-After-Read or Write-After-Write errors. These are synchronisation errors associated with updating a value while other threads are concurrently reading or updating the value.

To prevent synchronization errors you must use some form of locking mechanism. If you do use explicit locking you will need to be very careful about the order of acquiring locks. If you are not careful you can introduce deadlocks. For example: Thread A acquires Lock X, then Thread B acquires Lock Y. A while later Thread A requests Lock Y and Thread B requests Lock X. This causes both threads to wait indefinitely for Locks that will never be released.

Two good rules of thumb for locking:

• Acquire locks in a specific order (e.g. always acquire Lock X before Lock Y)
• Hold locks for as short a time as possible. Acquire them when you need them, and release them as soon as you're done with the.

If you never write to an object after its creation, you do not need to lock it before accessing it. Thus, you will not need to lock immutable objects.

Answer 4

I'd strongly recommend watching this presentation by Rich Hickey:

http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

Some amazing insights on immutability, identity, state and locking for parallel applications.