This discussion is archived
7 Replies Latest reply: Apr 17, 2013 7:20 AM by 235461 RSS

help with singleton and threads

235461 Newbie
Currently Being Moderated
Hi,

I am hoping someone can confirm my understanding of Singleton and Thread. I consider myself a beginner at understanding threads.

The application I am working with has one entry point as far as I can tell. In that main class, an object instance AAA aaa = AAA.getInstance(whatever) is created. AAA happens to be a Singleton. Subsequently, aaa is passed to constructors of other objects which all hold a reference to aaa. Therefore, in my mind, all the access to aaa happens via a known instantiated "single" instance of the object AAA.

Some of these subsequent classes fire off Threads, and this is where I get somewhat insecure about my assumption. If a class has that reference and it is the one firing off threads, don't they all just point to the same instance?

When a command like aaa.getVal() or aaa.setVal(value) happens in a thread, I can see that there might be some contention somehow, but is this not solved by either using static or volatile?

Thank you for any comments or suggested readings; I am reading a couple java books right now and am still not clear about the above. Maybe I'm being impatient/lazy but any feedback is welcome :)

Mike
  • 1. Re: help with singleton and threads
    handat Expert
    Currently Being Moderated
    You have some valid concerns there and I am glad you do. I have seen way too many programmers that never considered this and consequently designed crappy systems that couldn't be scaled.
    I won't give you the simple answer since that would be difficult to do, but I will give you some pointers and do recommend you do some research into synchronized code blocks as well as thread-lock to help you better understand what you have stumbled onto.
  • 2. Re: help with singleton and threads
    EJP Guru
    Currently Being Moderated
    I won't give you the simple answer since that would be difficult to do
    I will. The simple answer is that unless the singleton is immutable, you need to sequentialize access to it via synchronized methods, synchronized blocks, or java.util.concurrent locks. Not so difficult really.
  • 3. Re: help with singleton and threads
    Tolls Journeyer
    Currently Being Moderated
    I will ask why you;re passing this instance of AAA around though.
    After all, those classes can simpyl call AAA.getInstance() and get the instance without having to hold onto a reference to it themselves. That's sort of the point.
  • 4. Re: help with singleton and threads
    BIJ001 Explorer
    Currently Being Moderated
    However the question of thread-safety arises independently whether that object is passed around or whether each consumer grabs it by itself.
  • 5. Re: help with singleton and threads
    Tolls Journeyer
    Currently Being Moderated
    BIJ001 wrote:
    However the question of thread-safety arises independently whether that object is passed around or whether each consumer grabs it by itself.
    Oh yes, entirely agree.
    I should have made that clear.
    It just struck me as an odd thing to do.
  • 6. Re: help with singleton and threads
    796440 Guru
    Currently Being Moderated
    BIJ001 wrote:
    However the question of thread-safety arises independently whether that object is passed around or whether each consumer grabs it by itself.
    And also has nothing to do with whether the object in question is a singleton.
  • 7. Re: help with singleton and threads
    235461 Newbie
    Currently Being Moderated
    Thanks all.

    To answer some of the comments. Yes, I agree that passing around a singleton seems weird. This is inherited code. Mainly I did not know about synchronized and etc and have read up on it since. I could clean up this code and un-confuse it in a number of ways but I believe the main concern about threads was answered.

    The class AAA I was looking at talks to a server on another machine/platform which answers simple requests. AAA always opens an IP connection, issues the command, waits for a response, closes the connection.

    I need to think on this more carefully. The problem is that some of the commands make something happen in the real world (on the server). The GUI code could cause a conflict in the real world no matter if it is serialized. The user could request a change, and the server side will make the change start, and while that is happening and not completed, if the user issues a reversal or conflicting change... heck, I need to ask the server guy what he thinks will happen on his end.

    In any case thanks for all the comments.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points