• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Thread Synchronization

 
Ranch Hand
Posts: 182
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Synchronization won work if it is on different objects. Here how it is working? Please explain.....



}
OUTPUT : SCJP-1 SCJP-2 SCJP-3 SCEA-1 SCEA-2 SCEA-3 or SCEA-1 SCEA-2 SCEA-3 SCJP-1 SCJP-2 SCJP-3
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I told you that System.out is a static final reference to a PrintStream instance, and that a PrintStream's print() method uses a synchronized block that synchronizes on its intrinsic lock (using the this reference), could you then explain this behavior?
 
Sheriff
Posts: 9709
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just to be more specific than jelle, just look at the synchronization statement

synchronized(s)
 
Balaji Bang
Ranch Hand
Posts: 182
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
System.out is a static and if it is locking on this then I think Synchronization works. But there are 2 different anonymous Inner classes. In different classes does the synchronization work???
 
Ankit Garg
Sheriff
Posts: 9709
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes you have different anonymous inner classes, but both will share the same instance s i.e. System.out. And since you synchronize on s, so both the run methods in the anonymous inner classes will synchronize on the same object. If I modify your code, then the synchronization will not work



Now both methods will synchronize on different objects...
 
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jelle Klap wrote:If I told you that System.out is a static final reference to a PrintStream instance, and that a PrintStream's print() method uses a synchronized block that synchronizes on its intrinsic lock (using the this reference), could you then explain this behavior?


I understand what you are saying, but the statement marked as bold is not relevant for this example, correct?
 
Ankit Garg
Sheriff
Posts: 9709
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are right Ruben. The matter of concern for the question is that the synchronized blocks synchronize on the System.out object. It's not related to the print method...
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ruben Soto wrote:

Jelle Klap wrote:If I told you that System.out is a static final reference to a PrintStream instance, and that a PrintStream's print() method uses a synchronized block that synchronizes on its intrinsic lock (using the this reference), could you then explain this behavior?


I understand what you are saying, but the statement marked as bold is not relevant for this example, correct?



Well, yes and no.
It's important to understand that the output of both run() methods will never intertwine, because both run() methods synchronize on the same lock i.e. System.out's intrinsic lock.
It's also important to understand that, although the print() method also synchronizes on this lock, this is not a dead-lock scenario, because intrinsic locks are reentrant.
 
Ruben Soto
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jelle Klap wrote:

Ruben Soto wrote:

Jelle Klap wrote:If I told you that System.out is a static final reference to a PrintStream instance, and that a PrintStream's print() method uses a synchronized block that synchronizes on its intrinsic lock (using the this reference), could you then explain this behavior?


I understand what you are saying, but the statement marked as bold is not relevant for this example, correct?



Well, yes and no.
It's important to understand that the output of both run() methods will never intertwine, because both run() methods synchronize on the same lock i.e. System.out's intrinsic lock.
It's also important to understand that, although the print() method also synchronizes on this lock, this is not a dead-lock scenario, because intrinsic locks are reentrant.


I see what you mean. I wasn't aware of this, but unless you use some specialized API lock related class, aren't locks in Java always reentrant?
 
Ruben Soto
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ankit Garg wrote:You are right Ruben. The matter of concern for the question is that the synchronized blocks synchronize on the System.out object. It's not related to the print method...


Thanks Ankit, that's what I meant. But I think Jelle was trying to make a point about locks being reentrant. It's just that it wasn't clear from the wording used.
 
reply
    Bookmark Topic Watch Topic
  • New Topic