• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Synchronization

 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When would you use a synchronized method and when a synchronized block?

Thank you
 
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can give you the example of two implementations of the Singleton pattern


getInstance Option 1


getInstance Option 2

Both options will ensure that the Singleton's constructor will be called just one time.

With option 1, a lock is required every time the method getInstance is called, even if instance is not null.

With option 2, if instance has been created, no lock is required : the code seems to be more efficient.

Note that there are others problems with option 2 due to "out-of-order writes" but that's not the question...
[ September 29, 2005: Message edited by: Seb Mathe ]
 
author
Posts: 23951
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

With option 2, if instance has been created, no lock is required : the code seems to be more efficient.



First, synchronization is now much more efficient. I would not worry about it too much anymore.

Second, while the code in option 2 will work in getting you a singleton, there is no guarantee that "if instance has been created, no lock is required". The reason is because the compiler will detect the common condition, and optimize it by moving the outer loop into the synchronization block. Search "double checked locking" for more information.

Henry
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How to choose between writing a synchronized method or a synchronized block?

A synchronized method syncs on the object instance that is running the method. This may not be the right level of granularity for some problems. It may block other threads for longer than really necessary. Static methods have no "this" and lock on the class which is even larger granularity.

A synchronized block specifies what object we lock on, so it can use "this" or any other object that happens to be shared by multiple threads, including a static variable shared by all instances of the class. We can have a short synchronized block in the middle of a long running method and only lock for that short amount of time.

At a rather deep theoretical level a synchronized method is leaky encapsulation because it "exposes the monitor" which bothers some people a lot more than it does me.

Any of those notions help?
 
Seb Mathe
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, you confirm that optimizing is a diffucult thing for developers...

And I'm affraid that some commercial products implements Singleton pattern with "option 2"...



 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Seb Mathe:
Well, you confirm that optimizing is a diffucult thing for developers...

And I'm affraid that some commercial products implements Singleton pattern with "option 2"...



This has been well-known for years. There's no excuse for any professional Java developer not knowing about this.
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Option 2 is totally broken. Optimizing JVMs can set the reference before they finish creating the objects. Some question about if this is legal or not, but be careful. DCL is broken period, its not really a java issue, the theory behind it is flawed.

Never use synchronized methods, they expose the monitor object to the public. Violating encapsulation in the worse way. For a good example see the insides of Thread.join();
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, what than be the best option for the singleton, considering that option 2 is not appropiate as well as option 1, because it uses a synchronized method?

thx rudolf
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can give up on lazy instantiation and make an instance up front:

[ October 13, 2005: Message edited by: Stan James ]
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Singleton with lazy initialization

The instancee will be created when the class is loaded. Supposedly this works. Makes you wonder though why there is a difference between class loading and instance creating...
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm, we called exactly the same thing lazy and not lazy. By lazy I meant not created until you ask for it. With this static variable it will be created when the class is loaded, which could be triggered by Class.forName() or calls to other static methods. In real practice, referencing the class and asking for an instance is probably the same line of code so it matters darned little.

BTW: This is the simplest form I can think of for this, but not the only one. You could implement Singleton in several other interesting ways.
 
Rudolfoo Schmidt
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sometimes you hang on the lazy way, because the singleton needs some other things that won't be available until other constructors have be done.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can't think of a requirement to defer construction of the single instance until the class has done some other initialization. Or at least one I couldn't make go away. That would force users to do something like:

What are the chances one client would forget to do that?
[ October 14, 2005: Message edited by: Stan James ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic