7 Replies Latest reply: Apr 17, 2013 9:20 AM by mecase RSS

    help with singleton and threads

    mecase
      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
          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
            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
              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
                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
                  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
                    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
                      mecase
                      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.