• 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
  • Tim Cooke
  • Devaka Cooray
  • Ron McLeod
  • Jeanne Boyarsky
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Martijn Verburg
  • Frits Walraven
  • Himai Minh

Thread Safe Singleton section KS/BB OCJP - possible minor errata entry

 
Ranch Hand
Posts: 39
5
Spring Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is something I think is only slightly lacking in information, and possibly on purpose to aid the understanding of the reader without going beyond the scope of the exam too much...

Chapter 1, on P553.

The singleton code here assumes you are only running one thread at a time. It is NOT thread-safe. Think about if this were a web site and two users managed to be booking a seat at the exact same time. If getInstance() were running at the exact same time, it would be possible for both of them to see that INSTANCE was null and create a new Show at the same time. There are a few ways to solve this. One is to add synchronized to the getInstance() method. This works, but comes with a small performance hit. We're getting way beyond the scope of the exam, but you can Google "double checked locked pattern" for more information.



In particular...
"There are a few ways to solve this. One is to add synchronized to the getInstance() method."

As per my understanding, by just adding synchronized to the getInstance() method, it would risk the chance that the thread that initializes the singleton instance would cause the instance stay in thread local memory and not write through to the main memory for other threads to see, and would therefore not be 100% thread safe. However declaring the instance as volatile, however would ensure the JVM forces each thread to reconcile it's reference to the instance. So this section should read:

"There are a few ways to solve this. One is to add synchronized to the getInstance() method and declare the instance as volatile."

(Assuming I am right) I feel that the volatile addition would have been worth a mention. However I understand that it IS beyond the scope, and that eliding this information for the sake of brevity may have been preferable by Kathy/Bert. As such this is why I have added here rather than in the errata thread.

Thoughts?

p.s. Roel thanks for all your hard work compiling the errata! It is an extremely helpful resource.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

James Pittendreigh wrote:Thoughts?


I think when you mark the complete method as synchronizedyou don't need the volatile keyword (and that's exactly what the study guide suggests: One is to add synchronized to the getInstance() method.). Although that works, it comes with a performance hit (synchronizing a method could in some extreme cases decrease performance by a factor of 100 or higher). And one way to improve performance is to use the double-checked locking pattern and then you must use at least Java 5 and the volatile keyword. Sources: Singleton pattern and Double-checked locking

So I would not consider this as an errata item. But I'm definitely not an expert about threads, multi-threading and thread safety. If it turns out my thoughts are wrong, I'm happy to add it to the errata overview. I definitely know 1 thing: if I ever need a singleton, I would not use either of these solutions I would choose for eager initializationor initialization-on-demand holder idiomor the enum way

James Pittendreigh wrote:p.s. Roel thanks for all your hard work compiling the errata! It is an extremely helpful resource.


Thanks for these kind words. Highly appreciated!

Hope it helps!
Kind regards,
Roel
 
James Pittendreigh
Ranch Hand
Posts: 39
5
Spring Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your reply Roel, you are completely right here. I have done some additional reading on the subject and understand the reason why volatile is not needed when you synchronize access to the instance via getInstance.

I think I was under the illusion that if you didn't use volatile that other threads may see a "half-initialized" version of the instance, but seeing as the instantiation is done in the synchronized method (if you synchronize the getInstance() method), other threads would only get access to it after it has been fully initialized anyway.

Definitely not one for the errata. Thanks again for the detailed reply.
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

James Pittendreigh wrote:Thanks for your reply Roel, you are completely right here.


Phew!

James Pittendreigh wrote:Thanks again for the detailed reply.


As always, you are very welcome!
 
Put a gun against his head, pulled my trigger, now he's dead, that tiny ad sure bled
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic