6 Replies Latest reply: Nov 8, 2012 12:03 PM by 935199 RSS

    Question about synchronized re-entry

    935199
      Suppose I have the following code:
      /**
       * method performs actions that require synchronization on state but
       * the programmer ensures manually that it is only called in a context
       * where we are already synchronized on state
       */
      private void veryPrivateMethod() {
          //synchronized(state) { (*) required?
          if (state == 999) {
              // perform actions that require synchronization on state
          }
          //}
      }
      
      public void anotherMethod() {
          synchronized(state) {
              if (state == 42)
                  state = 43;
              veryPrivateMethod();
          }
      }
      See (*): If I ensure manually that veryPrivateMethod will only be called in a context where we are already synchronized on state, do I still need to specifically synchronize on state in the method (reentrant synchronization), or will it be better performance-wise and still safely synchronized if I omit the synchronized statement in veryPrivateMethod()?

      Thanks!
        • 1. Re: Question about synchronized re-entry
          jtahlborn
          first of all, you should never re-assign the reference to the object on which you are currently synchronizing, it will only confuse you and lead to "not-thread-safe" code.

          as to your question, no, the secondary synchronization is not "necessary". however, it will cause almost no performance hit as "re-entering" an already owned synchronized block is very cheap on modern jvms. design-wise, if you omit the secondary sync block, you need to be very careful that you do not introduce code in the future that calls that private method without first synchronizing.
          • 2. Re: Question about synchronized re-entry
            935199
            Thanks! I thought that was the case.

            About what you just said: In my actual program, state is actually an enum. I synchronize on it whenever I change / compare-change it. Is this a bad idea, given what you just said, or does what you just said only hold for objects?

            Thanks!
            • 3. Re: Question about synchronized re-entry
              jtahlborn
              an enum is an object, so, yes, what i said applies.
              • 4. Re: Question about synchronized re-entry
                gimbal2
                932196 wrote:
                I synchronize on it whenever I change / compare-change it. Is this a bad idea
                That's a maybe. Its not a bad idea, as long as you realize that doing this has no special meaning and will offer no special protection. You can synchronize on just about any object you want, as long as other threads synchronize on the exact same object when wanting to execute the same section(s) of volatile code.
                • 5. Re: Question about synchronized re-entry
                  jtahlborn
                  gimbal2 wrote:
                  932196 wrote:
                  I synchronize on it whenever I change / compare-change it. Is this a bad idea
                  That's a maybe. Its not a bad idea, as long as you realize that doing this has no special meaning and will offer no special protection. You can synchronize on just about any object you want, as long as other threads synchronize on the exact same object when wanting to execute the same section(s) of volatile code.
                  the comment in the example is:
                  // perform actions that require synchronization on state
                  this leads me to believe that the code is not correctly synchronized currently. like i said, changing the reference to the object you are synchronizing on pretty much always leads to broken code.
                  • 6. Re: Question about synchronized re-entry
                    935199
                    Thanks to both for the answer, I've understood the problems with synchronizing on a changing reference.