The purpose of purely functional data structures is generally not to be used as a shared, mutable source of data among multiple threads/processes. Hell, even in

The purpose of purely functional data structures is generally not to be used as a shared, mutable source of data among multiple threads/processes. Hell, even in a single process, this kind of serial access results in the same situation. The point of a purely functional data structure is to be able to pass it to another method/thread/whatever, without having to worry that the data will be modified without the caller context expecting it.. In terms of the type of pattern you're talking about (something like producer/consumer), an appropriate pattern in Scala might be to use an actor with an internal mutable data structure. Actors receive messages in a synchronized manner, and can then distribute work as needed. If the majority of your data is immutable, then beyond config for number of threads and actor mailbox size, there's very little you need to worry about - contention, lock granularity and race conditions are essentially non-issues. As a thought exercise, it would be possible to use an immutable queue with an actor for the above purpose. Create an actor that, when receiving a message containing an item to enqueue, waits until it receives a queue. When sent a message with a queue, it should take a message from the mailbox, enqueue it, then send the queue to a second actor. That actor will dequeue and operate on an item from its message, then send a message with the new queue (with one less item) to the original actor. The only time the original actor will do nothing is when it receives a message with an empty queue (which is how it will start, and also the state it will be in every time it has finished working its queue), in which case it will wait for an item to enqueue. Assuming that the "process a queue item" step is fast (as it should be), and the "wait for a queue" is not a busy wait (I think there is a way to do this with Akka), then this might actually be efficient. This is probably a bad idea though, just having fun thinking about how it would be possible. =)