Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!
  • 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
  • Liutauras Vilda
  • Tim Cooke
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Frank Carver
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • fred rosenberger

Yet another question on singletons and synchronicity

 
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Most of us use Singletons as kind of a memory storage in the JVM. Usual case is the values of a singleton class are set during application startup then accessed later on. At some processes or functions in the application, we update its values.

Ok so if we want to get value someParameter from singleton class SomeSingletonClass, we do this right?




What if this case happens:




Two questions on this:

1. How can I make it return "val2" ? is it even possible to do? I know this case will rarely happen but we want to cover all bases

2. Does this mean we should always use synchronized methods when processing or changing values of singleton classes? shouldn't a synchronized getInstance method be able to handle that? im confused




 
Saloon Keeper
Posts: 14324
321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If getSomeParameter() and setSomeParameter() are synchronized with one-another, a call to getSomeParameter() that happens-after a call to setSomeParameter() will return the updated value.

This has nothing to do with singletons, this happens with any thread-safe class that's shared between multiple threads.

The problem with singletons (or indeed, any globally accessible data) is that theoretically every thread in the application has immediate access to it. This will make your code impossible to test properly, and may even make it non-deterministic. That's why you should NEVER HAVE STATIC REFERENCES TO MUTABLE INSTANCES.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andres Delrotti wrote:Most of us use Singletons as kind of a memory storage in the JVM. Usual case is the values of a singleton class are set during application startup then accessed later on. At some processes or functions in the application, we update its values.


Really? I don't think I've ever used a Singleton like that. Indeed, other than enums, I can't remember the last time I used one at all.

2. Does this mean we should always use synchronized methods when processing or changing values of singleton classes? shouldn't a synchronized getInstance method be able to handle that? im confused


If indeed you do update your singleton (which sounds like a dubious practise to me to begin with), then if it also needs to be Thread-safe, you need to write it just as you would any other Thread-safe object; there's nothing special about the fact that it's a singleton.

So, yes, that means that you need to use synchronized and/or volatile just as you would for any other Thread-safe class.

Winston
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andres Delrotti wrote:Most of us use Singletons as kind of a memory storage in the JVM. Usual case is the values of a singleton class are set during application startup then accessed later on. At some processes or functions in the application, we update its values.


You mean that people use them as global variables. Global variables are bad and you should avoid them, because they can quickly turn your project into an unmaintainable ball of spaghetti.

Why global variables are bad: see Why is Global State so Evil?. In a multi-threaded program the problem will become even worse, because you have to be very careful to apply the right synchronization, which is easy to get wrong or forget somewhere.
 
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andres Delrotti wrote:
What if this case happens:




The part that I have emboldened doesn't make sense to me. Thread safety issues aside, getInstance() will always return the same object because you've said it's a singleton. Why would calling getInstance() again change anything?

Obviously if the singleton instance is not threadsafe then mutating it from multiple threads will lead to very confusing, non-deterministic behaviour as others have pointed out. And again as others have pointed out singletons are often a bad idea, especially used in the fashion you describe.

Are you aware of how to make an object thread safe?

Edit: Ok, it seems the markup doesn't work in the quotes! I've left it in so you can see which part I had intended to make bold though.
 
Ranch Hand
Posts: 239
12
Scala IntelliJ IDE Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I like all the posts. Stephan's post is important. Everyone should read that bold underlined part again! A good example of this is when an array of something is a static field.

So if you really have to for some reason have a singleton, and you really for some reason have to store a global value somewhere, its a good idea to mark the value final and not provide a setter.

This is good stuff: Java Practices - Use final liberally
 
Andres Delrotti
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alright. I get the message. I will review my other options.
 
Wink, wink, nudge, nudge, say no more, it's a tiny ad:
Garden Master Course kickstarter
https://coderanch.com/t/754577/Garden-Master-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic