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!

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:

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

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

Quote:

---

Originally Posted by MatuX

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

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

Quote:

---

Originally Posted by MatuX

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

Quote:

---

Originally Posted by JosAH

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

Quote:

---

Originally Posted by j2me64

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:

Code:

---

synchronized(this) {
  myString = "the quick brown fox";
}

---

...and another section of code that does not lock on 'this'

Code:

---

  myString = "jumps over the lazy dog";

---

...then the value of 'myString' is unpredictable.

Quote:

---

Originally Posted by j2me64

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

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?

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.

Quote:

---

Originally Posted by j2me64

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 :

Quote:

---

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?

Quote:

---

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.