How to handle concurrent access to a Scala collection?

Question

I have an Actor that - in its very essence - maintains a list of objects. It has three basic operations, an add, update and a remove (where sometimes the remove is called from the add method, but that aside), and works with a single collection. Obviously, that backing list is accessed concurrently, with add and remove calls interleaving each other constantly.

My first version used a ListBuffer, but I read somewhere it's not meant for concurrent access. I haven't gotten concurrent access exceptions, but I did note that finding & removing objects from it does not always work, possibly due to concurrency.

I was halfway rewriting it to use a var List, but removing items from Scala's default immutable List is a bit of a pain - and I doubt it's suitable for concurrent access.

So, basic question: What collection type should I use in a concurrent access situation, and how is it used?

(Perhaps secondary: Is an Actor actually a multithreaded entity, or is that just my wrong conception and does it process messages one at a time in a single thread?)

(Tertiary: In Scala, what collection type is best for inserts and random access (delete / update)?)

Edit: To the kind responders: Excuse my late reply, I'm making a nasty habit out of dumping a question on SO or mailing lists, then moving on to the next problem, forgetting the original one for the moment.

Answer 1

Take a look at the scala.collection.mutable.Synchronized* traits/classes.

The idea is that you mixin the Synchronized traits into regular mutable collections to get synchronized versions of them.

For example:

import scala.collection.mutable._
val syncSet = new HashSet[Int] with SynchronizedSet[Int]
val syncArray = new ArrayBuffer[Int] with SynchronizedBuffer[Int]

Answer 2

Scala's immutable collections are suitable for concurrent usage.

As for actors, a couple of things are guaranteed as explained here the Akka documentation.

• the actor send rule: where the send of the message to an actor happens before the receive of the same actor.
• the actor subsequent processing rule: where processing of one message happens before processing of the next message by the same actor.

You are not guaranteed that the same thread processes the next message, but you are guaranteed that the current message will finish processing before the next one starts, and also that at any given time, only one thread is executing the receive method.

So that takes care of a given Actor's persistent state. With regard to shared data, the best approach as I understand it is to use immutable data structures and lean on the Actor model as much as possible. That is, "do not communicate by sharing memory; share memory by communicating."