• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

Yet another question on singletons and synchronicity

 
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
  • 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: 12488
269
  • Mark post as helpful
  • send pies
  • 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: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • 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
  • 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
  • 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
  • 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
  • Quote
  • Report post to moderator
Alright. I get the message. I will review my other options.
 
Ever since I found this suit I've felt strange new needs. And a tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic