11 Replies Latest reply: Feb 25, 2009 4:47 PM by 3004 RSS

    which object's monitor does a synchronized method acquire?

    843785
      from the Java Tutorial for concurrency programming:

      " When a thread invokes a synchronized method, it automatically acquires the intrinsic lock _for that method's object_ and releases it when the method returns. The lock release occurs even if the return was caused by an uncaught exception. "

      what exactly does this mean?
      do synchronized methods acquire the monitors for objects of type: java.lang.reflection.Method
      please consider this code:
      public class Foo {
        .....
        private int counter = 0;
      
        public synchronized void incriment() { counter++; }
        public synchronized void decriment() { counter--; }
       .....
      }
      
      ......
      Foo f = new Foo();
      Class[] sig = new Class[0];
      Method m = f.getClass().getMethod("incriment", sig);
      // ok. so "m" is the relevant method object.
      f.incriment(); // <-- is the monitor for "m" , 
                            // or the monitor for "f", acquired? 
      .......
      my reading of the Concurrency Tutorial is that synchronized methods use the monitors of java.lang.reflection.Method objects?
      and thus, Foo is not thread safe, right?

      however, this simple change makes Foo thread-safe?
      public class Foo {
        .....
        private volatile int counter = 0; // "volatile"
      
        public void incriment() { counter++; }
        public void decriment() { counter--; }
       .....
      }
      thanks.

      Edited by: kogose on Feb 23, 2009 7:13 PM
        • 1. Re: which object's monitor does a synchronized method acquire?
          3004
          class Foo {
            synchronized void bar() {
              // body
            }
            
            // is the same as
          
            void bar() {
              synchronized (this) {
                // body
              }
            }
          
          
            // and
          
          
            static synchronized qux() {
              // body
            }
          
            // is the same as 
          
            static qux() {
              synchronized (Foo.class) {
                // body
              }
            }
          }
          In all cases, you're just syncing on an object, and which object doesn't matter, except to other methods or blocks that sync on the same object. Everything else is identical, "as far as the behavior of the threads is concerned".

          * There's a slight difference in the bytecode and VM details, but it's not relevant here.
          • 2. Re: which object's monitor does a synchronized method acquire?
            3004
            which object's monitor does a synchronized method acquire?
            this, for non-static methods
            • 3. Re: which object's monitor does a synchronized method acquire?
              796447
              f.incriment(); // <-- is the monitor for "m" ,
              // or the monitor for "f", acquired?
              The monitor for the object that f is referencing. Certainly not what "m" is referencing.
              • 4. Re: which object's monitor does a synchronized method acquire?
                3004
                kogose wrote:
                my reading of the Concurrency Tutorial is that synchronized methods use the monitors of java.lang.reflection.Method objects?
                No, that's wrong.
                • 5. Re: which object's monitor does a synchronized method acquire?
                  843785
                  so its fair to say:

                  (-) an object only knows its Class. (but not its Methods)
                  (-) a Class knows its Methods.
                  (-) a Method knows its Class.

                  and nothing could be gained by trying to synchronize on a Method's lock,
                  though synchronizing on a Class's lock happens all the time.
                  because that is how the "synchronized static" methods work.
                  • 6. Re: which object's monitor does a synchronized method acquire?
                    791266
                    kogose wrote:
                    so its fair to say:

                    (-) an object only knows its Class. (but not its Methods)
                    (-) a Class knows its Methods.
                    (-) a Method knows its Class.
                    I don't know what you mean by those statements, but the first statement looks odd.
                    and nothing could be gained by trying to synchronize on a Method's lock,
                    Correct
                    though synchronizing on a Class's lock happens all the time.
                    Hm. Not too sure about that. I seldom write static methods, and they are almost never sychronized.
                    because that is how the "synchronized static" methods work.
                    See above.
                    • 7. Re: which object's monitor does a synchronized method acquire?
                      843785
                      kogose wrote:
                      what exactly does this mean?
                      It means you're complicating things.

                      If a method is synchronized, it is. You don't need to go beyond that. The method is synchronized.
                      • 8. Re: which object's monitor does a synchronized method acquire?
                        3004
                        tensorfield wrote:
                        kogose wrote:
                        what exactly does this mean?
                        It means you're complicating things.

                        If a method is synchronized, it is. You don't need to go beyond that. The method is synchronized.
                        Not true. You have to know what it means for a method to be synchronized. Often people come in with the erroneous impression that it somehow prevents you from using or accessing the object in any other thread.
                        • 9. Re: which object's monitor does a synchronized method acquire?
                          843785
                          jverd wrote:
                          tensorfield wrote:
                          kogose wrote:
                          what exactly does this mean?
                          It means you're complicating things.

                          If a method is synchronized, it is. You don't need to go beyond that. The method is synchronized.
                          Not true. You have to know what it means for a method to be synchronized. Often people come in with the erroneous impression that it somehow prevents you from using or accessing the object in any other thread.
                          That's exactly why I suggested that people learn what a synchronized method is.

                          It's very simple. If a synchronized method is called at the same time from many threads only one call will be executed at a time. The calls will be lined up and performed one after the other in sequence.

                          AND because synchronization is on a per object basis, when one synchronized method is being called from one thread, all synchronized methods of that same object are blocked for calling from other threads.

                          Simple as that.
                          • 10. Re: which object's monitor does a synchronized method acquire?
                            843785
                            not "that" simple to me because i am new to java.
                            watching two threads interleafing the execution of a locked Method
                            is interesting. it could have open some design opportunities.
                            • 11. Re: which object's monitor does a synchronized method acquire?
                              3004
                              tensorfield wrote:
                              jverd wrote:
                              tensorfield wrote:
                              kogose wrote:
                              what exactly does this mean?
                              It means you're complicating things.

                              If a method is synchronized, it is. You don't need to go beyond that. The method is synchronized.
                              Not true. You have to know what it means for a method to be synchronized. Often people come in with the erroneous impression that it somehow prevents you from using or accessing the object in any other thread.
                              It's very simple. If a synchronized method is called at the same time from many threads only one call will be executed at a time. The calls will be lined up and performed one after the other in sequence.
                              AND because synchronization is on a per object basis, when one synchronized method is being called from one thread, all synchronized methods of that same object are blocked for calling from other threads.
                              Simple as that.
                              No, it's not that simple, and as stated, that is not correct. In particular, you didn't mention that for an instance method, all the various threads have to be trying to call instance methods on the same object in order for execution to be sequential.

                              You really can't understand Java's syncing without understanding how it relates to locks, and what it means for a method to be synchronized in terms of which lock it acquires.

                              Edited by: jverd on Feb 25, 2009 2:47 PM