iterating list in multi threaded environment

[s ravi chandran]

Hi,
I have a question, recently I had a scenario where multiple threads where calling a class which used same arraylist object. Now the list is not being modified anywhere, still I added a synchronized block for safety reasons. I was asked why I added the block when there is no modification. I had no answer. I have doubt, will multiple thread iterating the same arraylist create any issue? the iterator class is static right?

[Mike Simmons]

If no modification of the list occurs after it was created, and the list is safely published to the other threads, then it's safe to iterate any way you want. However you may want to read up on safe publication if you're not familiar with it. I haven't checked the linked article carefully; if it doesn't help, Google "safe publication java" for more, or read Java Concurrency in Practice for all the details.

[s ravi chandran]

Mike Simmons wrote:If no modification of the list occurs after it was created, and the list is safely published to the other threads, then it's safe to iterate any way you want. However you may want to read up on safe publication if you're not familiar with it. I haven't checked the linked article carefully; if it doesn't help, Google "safe publication java" for more, or read Java Concurrency in Practice for all the details.

Thanks for the reply. I list is populated before it is read by any thread. Only doubt I had was from what I know, Iterator is static inner class, so will it effect the iteration from other thread or not. If it is safe then I do not need the synchronization.

[Junilu Lacar]

That the iterator implementation is a static inner class has no bearing on its thread safety; it's just a way to limit the scope of that particular iterator. If you are always using a local variable to reference it then you should have no problem with concurrency with respect to the iterator.

[Henry Wong]

Interestingly, there are actually a few good reasons to synchronize the reads of an arraylist, when it is used in a multithreaded fashion, even if it is always for iterating/reading.

1. The application may be changed in the future. Multithreaded applications can get complicated, so it may be a good idea to think about thread safety as soon as the application becomes multithreaded -- instead of thinking about thread safety only when a complicated multithread application's algorithm changes to need to do a write.

2. The List implementation may change. Yes, the ArrayList is guaranteed to be thread safe, provided that the list doesn't structurally change. I believe that this may be true for all the core List implementations -- but is it always true? People generally don't think about thread safety when changing a line from "List l = new ArrayList()" to "List l = new MyRemoteDatabaseList()" -- mainly because an ArrayList is not expected to be thread safe. And what if this new list doesn't have this subtle guarantee? So, if this change is made years later, or is made by someone else, it may cause problems that is very difficult to detect.

Henry

[Mike Simmons]

Hmmm, perhaps. But there is also a good reason *not* to synchronize here - it reduces lock contention. If multiple threads want to iterate the same list at the same time, this can be a signficant effect.

It's interesting to consider how best to future-proof your code here. I would argue that it would be best to limit direct access to the list that will be iterated. Don't allow other classes to get() the list of you can help it, as the authors and editors of those classes aren't necessarily familiar with the thread-safety requirements of your class. Instead, let the other classes call a method that will handle the iteration for them. That method will be responsible to perform the iteration in a thread-safe manner.

It's still possible that someone will change something in the future and screw it up - but at least, is less likely if synchronization decisions don't need to be made by all the clients of a class. Only the editors of the class that owns the list need to know the details.

I would also be inclined to make the list unmodifiable, and put a comment or annotation at the declaration of the list, indicating that this is important for thread safety. Yeah, a comment can be ignored - but this is a reasonable safety precaution, I think.

[Junilu Lacar]

Mike Simmons wrote:
It's interesting to consider how best to future-proof your code here. I would argue that it would be best to limit direct access to the list that will be iterated. Don't allow other classes to get() the list of you can help it, as the authors and editors of those classes aren't necessarily familiar with the thread-safety requirements of your class. Instead, let the other classes call a method that will handle the iteration for them. That method will be responsible to perform the iteration in a thread-safe manner.
...
I would also be inclined to make the list unmodifiable, and put a comment or annotation at the declaration of the list, indicating that this is important for thread safety. Yeah, a comment can be ignored - but this is a reasonable safety precaution, I think.

Makes me think of "Tell, Don't Ask" - with Java 8, the owner of the list could provide a method that takes a lambda that will then be used in whatever manner is appropriate for thread safety, including operating on a copy or unmodifiable version of the list. Clients would then just provide the list processing logic encapsulated in the lambda instead of asking for a reference to the list.

[s ravi chandran]

Okay, my original intention with the synchronized block was to prevent any possible misuse of the list in anyway. I did not think about what conflict it might have in multi threaded environment. But as mike said, a method handling the iteration in place of the list iteration directly will be a better approach for me. I have not reached java 8 yet so not familiar with the use case of Lamda function, but have some idea from projects on javascript about how it will look like.