• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Synchronize an instance variable

 
W Lin
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



There are 3 "MyRunnable" instance, and "i" is NOT a static attribute, so they use different lock, BUT WHY the code output like this:



If I change "synchronized(i)" to "synchronized(this)", it works as expected:



I don't understand the first output...
 
Paul Clapham
Sheriff
Posts: 21111
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the first example (which is the one you're asking about, right?) the three threads synchronize on different objects. If I'm not mistaken, you already understood this part.

So the three threads are essentially unsynchronized and none of them prevent any other from running at any time. So you shouldn't expect thread A to do anything before thread B does anything, or vice versa. However you're asking a question about that, which seems to imply you are expecting some particular ordering of the output. Can you explain what that ordering is, and why you expect it?
 
Henry Wong
author
Marshal
Pie
Posts: 21184
80
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hint: it is related to autoboxing and the integer cache.
 
W Lin
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paul, I don't understand this -- "So you shouldn't expect thread A to do anything before thread B does anything, or vice versa"

I expect the output to be in random order (similar to the 2nd output -- A/B/C in random order), because the 3 threads each locks its own "i" and they run simultaneously.



Paul Clapham wrote:In the first example (which is the one you're asking about, right?) the three threads synchronize on different objects. If I'm not mistaken, you already understood this part.

So the three threads are essentially unsynchronized and none of them prevent any other from running at any time. So you shouldn't expect thread A to do anything before thread B does anything, or vice versa. However you're asking a question about that, which seems to imply you are expecting some particular ordering of the output. Can you explain what that ordering is, and why you expect it?
 
Henry Wong
author
Marshal
Pie
Posts: 21184
80
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
W Lin wrote:Hi Paul, I don't understand this -- "So you shouldn't expect thread A to do anything before thread B does anything, or vice versa"

I expect the output to be in random order (similar to the 2nd output -- A/B/C in random order), because the 3 threads each locks its own "i" and they run simultaneously.



Paul is actually correct, you shouldn't expect a random order just because the execution is not synchronized..... however, since you added a delay with each iteration (in the example), it is highly unlikely that the output won't interlace..... so, I guess you are both right....

Regardless, for the answer, see my last hint.

Henry
 
W Lin
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Hint: it is related to autoboxing and the integer cache.


OMG, thanks a lot! This is so tricky



the output is:



If I change

to


the output is:



None of the book mentions it. Thanks a lot again!
 
Paul Clapham
Sheriff
Posts: 21111
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Hint: it is related to autoboxing and the integer cache.


Ouch.
 
R. Jain
Ranch Hand
Posts: 375
1
Java Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Lin,

Just saw your previous reply to this post, and am wondering is it really happening???
I Mean,

private String s = "";
and
private String s = new String("");

are no different. Both will create a new String object on Heap every time a thread is started.... So how can there be difference in output for the two cases???
 
R. Jain
Ranch Hand
Posts: 375
1
Java Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Man you are right.... Its giving that weird output... And I can't figure it out how is it happening...
Can anyone explain this to me, why is there a difference in using both these definition of String variable???
 
Henry Wong
author
Marshal
Pie
Posts: 21184
80
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
R. Jain wrote:
Just saw your previous reply to this post, and am wondering is it really happening???
I Mean,

private String s = "";
and
private String s = new String("");

are no different. Both will create a new String object on Heap every time a thread is started.... So how can there be difference in output for the two cases???


This second example is similar. The first example was due to the integer cache. This second example is caused by the string pool.

Henry
 
R. Jain
Ranch Hand
Posts: 375
1
Java Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
R. Jain wrote:
Just saw your previous reply to this post, and am wondering is it really happening???
I Mean,

private String s = "";
and
private String s = new String("");

are no different. Both will create a new String object on Heap every time a thread is started.... So how can there be difference in output for the two cases???


This second example is similar. The first example was due to the integer cache. This second example is caused by the string pool.

Henry


Ok, Got it...
Thanks.. This thing just slipped away from my mind
 
R. Jain
Ranch Hand
Posts: 375
1
Java Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
W Lin wrote:
Henry Wong wrote:
Hint: it is related to autoboxing and the integer cache.


OMG, thanks a lot! This is so tricky



the output is:



If I change

to


the output is:



None of the book mentions it. Thanks a lot again!



Well, K&B does... You might not have noticed clearly..

Anyways... Henry just gave a nice hint.... Let me explain it little more....

The effect you get using: - String s = new String("")
will be same that you get while using: - Integer i = Integer.valueOf(4);

Actually JVM maintains a chache of all integers between the range -128 to 127.. So, you will get the same object everytime you use something like: - Integer i = 5; or, Integer i = new Integer(5);
Same is the case with String s = "Hello", where 's' will be added to the String Pool... And if there is already a literal in the pool with that value... "s" will simply point to the same object....
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic