This discussion is archived
6 Replies Latest reply: Nov 8, 2012 10:03 AM by 935199 RSS

Question about synchronized re-entry

935199 Newbie
Currently Being Moderated
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 Expert
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Expert
    Currently Being Moderated
    an enum is an object, so, yes, what i said applies.
  • 4. Re: Question about synchronized re-entry
    gimbal2 Guru
    Currently Being Moderated
    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 Expert
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    Thanks to both for the answer, I've understood the problems with synchronizing on a changing reference.

Legend

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