Results 1 to 13 of 13
  1. #1
    MatuX is offline Member
    Join Date
    Dec 2008
    Posts
    4
    Rep Power
    0

    Default Threading: Locking an object?

    Hey guys!

    There is something I just can't wrap my head around...

    I have a class with a private String "myString".

    That class has a getMyString() which returns the string and a setMyString() which sets the string.

    If I have one thread accessing getMyString() and another accessing setMyString(), things will go wrong, right?

    Then, how would I acquire a lock on myString?

    Everyone says to "just" use a synchronized block, but I just can't understand how to do such thing in this case!

    Best regards,
    Matias

    p.s.:
    if I make both getMyString() and setMyString() methods synchronized, that would only prevent two threads from accessing the SAME method, right?
    Please, help me understand because I'm having issues understanding how Java handles this!

  2. #2
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,309
    Blog Entries
    7
    Rep Power
    20

    Default

    When you make a method synchronized it synchronizes on the entire 'this', not just on your String myString. When you synchronize a static method it synchronizes on the entire class. If you want to lock (synchronize) on your String myString make a synchronized block:

    Java Code:
    synchronized (myString) {
       ...
    }
    The object you synchronize on (the entire class, this or myString) holds a monitor and the synchronized block/method is the 'owner' of that monitor. If something else wants to synchronize on the same thing it has to wait until the 'owner' releases the monitor.

    kind regards,

    Jos

  3. #3
    MatuX is offline Member
    Join Date
    Dec 2008
    Posts
    4
    Rep Power
    0

    Default

    Hey Joe,

    Thanks for your prompt response! I really appreciate it!

    But does this applies to that same block of code? Or to any?

    For example:

    String myString;

    public synchronized String getMyString();
    public synchronized void setMyString(String);

    if Thread 1 enters "setMyString"
    and then Thread 2 enters "getMyString"

    will Thread 2 wait until setMyString block returns?

    Thanks a lot!
    Matias

  4. #4
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,309
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by MatuX View Post
    Hey Joe,

    Thanks for your prompt response! I really appreciate it!

    But does this applies to that same block of code? Or to any?

    For example:

    String myString;

    public synchronized String getMyString();
    public synchronized void setMyString(String);

    if Thread 1 enters "setMyString"
    and then Thread 2 enters "getMyString"

    will Thread 2 wait until setMyString block returns?
    Yep, the first method gets the monitor on the 'this' object and the second method has to wait because it also wants to get that lock on the same object. So effectively only one or the other execute.

    kind regards,

    Jos

  5. #5
    MatuX is offline Member
    Join Date
    Dec 2008
    Posts
    4
    Rep Power
    0

    Default

    Now I finally understand... Thanks a lot man. This really helped me!

  6. #6
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,309
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by MatuX View Post
    Now I finally understand... Thanks a lot man. This really helped me!
    Good; you're welcome; better don't lock on your variable myString if it can be null. As it is now (locking on 'this') is fine because 'this' always exists (you'd have gotten a NullPointerException if no such object existed).

    kind regards,

    Jos

  7. #7
    j2me64's Avatar
    j2me64 is offline Senior Member
    Join Date
    Sep 2009
    Location
    Zurich, Switzerland
    Posts
    962
    Rep Power
    5

    Default

    Quote Originally Posted by JosAH View Post
    If you want to lock (synchronize) on your String myString make a synchronized block:
    synchronized (myString) {
    ...
    }

    i'm just studying threads for the scjp certification so i have a question about the code above. the myString is locked inside the block and the whole block is synchronized. but if there are other blocks or methods in your class the also modify the myString, what happens with myString? perhaps this is a silly question because you shouldn't never modify the myString variable outside the synchronized block, or what? please, illuminate me ...

  8. #8
    toadaly is offline Senior Member
    Join Date
    Jan 2009
    Posts
    671
    Rep Power
    6

    Default

    Quote Originally Posted by j2me64 View Post
    i'm just studying threads for the scjp certification so i have a question about the code above. the myString is locked inside the block and the whole block is synchronized. but if there are other blocks or methods in your class the also modify the myString, what happens with myString? perhaps this is a silly question because you shouldn't never modify the myString variable outside the synchronized block, or what? please, illuminate me ...
    Since Strings are immutable, using a String to discuss locks is not the best example. But anyway, a lock does not lock a variable, it locks code. Only 1 thread at a time can execute code that holds a given lock.

    If you had a section of code that did this:

    Java Code:
    synchronized(this) {
      myString = "the quick brown fox";
    }
    ...and another section of code that does not lock on 'this'

    Java Code:
      myString = "jumps over the lazy dog";
    ...then the value of 'myString' is unpredictable.

  9. #9
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,309
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by j2me64 View Post
    i'm just studying threads for the scjp certification so i have a question about the code above. the myString is locked inside the block and the whole block is synchronized. but if there are other blocks or methods in your class the also modify the myString, what happens with myString? perhaps this is a silly question because you shouldn't never modify the myString variable outside the synchronized block, or what? please, illuminate me ...
    If myString can have the value null better not synchronize on that object at all. AAMOF, if it can be changed also don't synchronize on it because synchronization is on objects themselves, not on their references.

    Of course if an object is changed in a synchronzed block as well as outside of one in another thread, the syncing will be useless. As a rule of thumb: any 'critical resource' should onlt be accessed in synchronized code so that only one thread at any moment can access it. Of course all threads should play a fair game and sync on the same object.

    kind regards,

    Jos

  10. #10
    j2me64's Avatar
    j2me64 is offline Senior Member
    Join Date
    Sep 2009
    Location
    Zurich, Switzerland
    Posts
    962
    Rep Power
    5

    Default

    ok, with the given example is there a difference between this two lines of code?

    1. synchronized(this) {}
    2. synchronized(myString) {}

    clear, this is a reference to the instance and myString is a variable of the type String. and what else?
    Last edited by j2me64; 06-08-2010 at 01:50 PM.

  11. #11
    Norm's Avatar
    Norm is online now Moderator
    Join Date
    Jun 2008
    Location
    SW Missouri
    Posts
    17,271
    Rep Power
    25

    Default

    Yes they would be different if this is not a reference to myString.
    Every object has a monitor that you can queue on.

    The syntax: synchronized(object)

    If two thread issue synchronized() on the SAME object, one gets the lock and the other goes into the queue to wait for the first one to exit the synchronized block.

  12. #12
    j2me64's Avatar
    j2me64 is offline Senior Member
    Join Date
    Sep 2009
    Location
    Zurich, Switzerland
    Posts
    962
    Rep Power
    5

    Default monitor for dummies

    Quote Originally Posted by j2me64 View Post
    clear, this is a reference to the instance and myString is a variable of the type String. and what else?

    i found an answer here :

    Unlike synchronized methods, synchronized statements must specify the object that provides the intrinsic lock:

    so the synchronized statements will be synchronized and you have to pass an object that can be used as lock, also called monitor. if my understanding is right, the monitor itself don't need to have any relation with the synchronized statements, but typically an object inside the synchronized statements is used. do the thread experts agree with me?

  13. #13
    Norm's Avatar
    Norm is online now Moderator
    Join Date
    Jun 2008
    Location
    SW Missouri
    Posts
    17,271
    Rep Power
    25

    Default

    monitor itself don't need to have any relation with the synchronized statements
    Yes. All the threads must agree to use the SAME object for the locking/queuing.

Similar Threads

  1. locking strategies
    By jicxicmic in forum JDBC
    Replies: 0
    Last Post: 09-03-2009, 11:36 PM
  2. locking keyboard and mouse
    By vibhor in forum AWT / Swing
    Replies: 4
    Last Post: 02-26-2009, 11:12 PM
  3. Row level locking........
    By jithan in forum New To Java
    Replies: 0
    Last Post: 09-02-2008, 07:09 AM
  4. row level locking
    By jithan in forum New To Java
    Replies: 1
    Last Post: 08-28-2008, 06:42 PM
  5. Locking window in java
    By coco in forum AWT / Swing
    Replies: 1
    Last Post: 07-31-2007, 07:21 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •