Should Collections be used as return types across threads?

Question

I am wondering when, if ever, it is appropriate to use a Collection as the return type of a method in a multi-threaded environment. Here is our situation:
We have four classes -- Widget, WidgetManager, ClientA, and ClientB. ClientA and ClientB are running in different Threads from each other and from the WidgetManager.
The WidgetManager class that uses a Collection of Widgets internally, and passes the Collection (or an Iterator over it) out as a return value of a method to ClientA, which is running in another thread. ClientA would start to go through it using next() and hasNext() of the Iterator. If the WidgetManager were to get a request from ClientB running in another thread to eliminate a Widget, it would attempt to remove it from the Collection. If ClientA were still looping through the Iterator, this would throw an IllegalStateException b/c the system would be in an inconsistent state. The Iterator given to the ClientA is directly linked to the actual Collection in the WidgetManager (am I right so far?).
In my opinion, in most cases we don't want to synchronize Collections. In the example above, if we had passed out a synchronized Collection, then the WidgetManager couldn't touch the collection while the client was looping through the Iterator. If the client got hung up while looping, then the WidgetManager would be hung up. In this case, I think that it will be better to use the toArray() method of Collection to just dump out the contents to a plain array of Objects. Actually, the WidgetManager could convert this array of Objects to an array of Widgets before passing it out, which would give us the type checking that we don't get with Containers.
The condition where you would want to use a synchronized Collection would be when you actually want the client to do some writing or removing from the Collection. I would expect this to be pretty rare since you usually dont want to give clients access to an interal member (the Collection) of a class.
I think that it is also possible to have read-only Collections, but I think (don't know for sure) that you would still have the same IllegalStateException or synchronization probelms.
Can someone point out the errors in my thinking? Or should you generally only use Collections as internal members in a multi-threaded environment, and use toArray() whenever you want to pass the Collection's data outside of the class?
Thanks for any help.
Keith

Answer 1

I haven't tested what happens when you synchronize the
Collection, but I think that you are right. But this
causes the problem that I mentioned in the first post.
That is, what happens if your client STARTS running
through the Iterator, and then stops or gets hung up
for some reason? I assume that you're still blocked.
And it's pretty important to me in this case to not
t be blocked -- WidgetManager is the highest level
class in the system.
I'd like to know if anyone has tested this.
The Iterator implementations used in java.util do not use any synchronization by itself, (which is what you would expect since synchronization over multiple method call will involve much more complications and slower performance) . With iterator, you have to provide the necessary synchronization yourself to maintain thread-safety like this
Iterator itr = get Iterator from collectionInstance ;
synchronized(collectionInstance) {
while(itr.hasNext())
process itr.next() ...
As long as your client code gracefully exits the synchronized block on a stop( or hangup, given that it is detected and handled fast enough), it will not be a problem.
Also, I'd like an example of when you WOULD want to
return a Collection. I'm specifically interested in
when you would want to return one in a multi-threaded
environment, but I'm beginning to wonder when you
would EVER want to return one from a method.
Collections are great for internal uses, but you lose
type-checking and you expose the internals of your
class to modification when you use them as return
types. And if you're returning a read-only
Collection, you might as well return an array, right?Using a read-only proxy will be much faster and space-efficient than toArray().