• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Clarification on Collections.synchronizedList

 
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This method will give the thread safe list.

However javadoc says that the user has to use the synchronize block to avoid deadlock.
Instead of using this method and using the synchronize block on the original list object also we can avoid deadlock.


From java doc :
List list = Collections.synchronizedList(new ArrayList());
synchronized(list) { }

Instead of this :

List list = new ArrayList();
synchronized(list) { }


What is the use of the " Collections.synchronizedList " method?
 
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I strongly advise you to read the official javadoc, here is proper link on Oracle site:
http://download-llnw.oracle.com/javase/6/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29

Link you provided directs to this site:
http://www.aspose.com/categories/java-components/aspose.total-for-java/default.aspx
and this is not official javadoc documentation.

Here is an excerpt from documentation regarding synchronizedList function:


Returns a synchronized (thread-safe) list backed by the specified list. In order to guarantee serial access, it is critical that all access to the backing list is accomplished through the returned list.

It is imperative that the user manually synchronize on the returned list when iterating over it:

List list = Collections.synchronizedList(new ArrayList());
...
synchronized(list) {
Iterator i = list.iterator(); // Must be in synchronized block
while (i.hasNext())
foo(i.next());
}

Failure to follow this advice may result in non-deterministic behavior.


They say that you must synchronize only when iterating over list using iterator.
There is nothing about deadlock.
Other access (not through iterator) is guaranteed to be thread safe without special synchronization,
but only when you access this list through list (reference) returned from this function, not through reference to backed (original) list.

 
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could also use classes from the java.util.concurrent.* package. Such as the CopyOnWriteArrayList. Then you don't need external synchronization because (most) use-case are covered by the class itself.
 
Thennam Pandian
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Thanks all for your replies.

My question is why should i use synchronized block while iterating the synchronized list ?

How about other operations? Are they thread-safe?

let say add method, If it is thread safe, what is the logic behind the method "Collections.synchronizedList"?

 
Sheriff
Posts: 22656
126
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When you synchronize your List using that method, all of its direct methods (add, remove, size, clear, etc) will be fully synchronized. However, any combination of calls still isn't. This is exactly what the iteration process does - combine multiple calls. As an example, let's look at iterating without an Iterator:
Even though list.size() and list.get(i) are both synchronized, without extra synchronization it's still possible to add or remove elements while iterating. By synchronizing on the entire block you prevent this:
 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I hope I'm not breaking any rules by waking up this old thread.

When synchronizing on the list as in Rob Spoor's message, how is the list protected when another thread modifies the list (e.g. adds an object to it), in a piece of code that is not synchronized on the list. E.g.:




If thread 1 is at point B, and thread 2 takes over then, and modifies the list at point A, doesn't that mean trouble?

The source code of SynchronizedList shows that its methods synchronize on a separate object (called mutex), and not on the list itself.
 
author
Posts: 23923
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jan Sterk wrote:
When synchronizing on the list as in Rob Spoor's message, how is the list protected when another thread modifies the list (e.g. adds an object to it), in a piece of code that is not synchronized on the list. E.g.:



Synchronization is cooperative. It doesn't magically makes things thread safe. If you use in incorrectly, it won't be thread safe. This includes not synchronizing across multiple methods when it is needed across multiple methods (the question related to this topic), and synchronizing access with some threads and not with others (which is what you are asking).

Synchronization is simply a tool to obtain thread safety.

Henry
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic