Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!
  • 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
  • Liutauras Vilda
  • Tim Cooke
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Frank Carver
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • fred rosenberger

Synchronization Question

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hypothetically say I have a Class (Class A) which contains a synchronized method (Method A) and a nested class (Class B) that contains a synchronized method (Method B) and Class A has a reference to Class B. If a thread calls method A, a lock is obtained on Class A till it has finished, which I understand. My question is what happens to Class B? Is the Class B object also locked? Or are they treated as two completely separate objects so the locking of one is independant of the locking of another. I wasn't sure how this is handled with nested classes, inner classes, etc, etc...

Thanks in advance!

Joshua
 
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It would be a great practice exercise to write code that demonstrates this.
 
Ranch Hand
Posts: 278
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
According to what i understood form y question,
you saying,
A is a class with some inner class B
A having synchronized methodA() ans in B is synchrnoized methodB()

object of B ,say b wont exist with obecjt of A say a
so always tied to outer class object.
in case a(object ) is locked because of methodA,means full object is locked,that means for that perticaular instance ,a,no other thread can access any data or method of a,
so b(instance var of class A ) is also locked.
 
marc weber
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lucky J Verma:
...in case a(object ) is locked because of methodA,means full object is locked,that means for that perticaular instance ,a,no other thread can access any data or method of a,...


If one thread has the lock on an instance of A, does that really mean that no other thread can access anything in the instance of A? Or does it mean that no other thread can access synchronized code in that instance?
 
Ranch Hand
Posts: 424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Marc and everyone, I ve written a test program to represent the problem posted by Joshua Mark, but I m not sure if its done correctly, please give me feedback.

a snippet from the output:

in A...
in B...
in A...
in B...
in A...
in B...
in A...
in B...
in A...
in B...
in A...
in B...

From what I see 2 threads can still access the 2 synchronized methods in class A and B and dont block each other.
 
marc weber
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ahmed Yehia:
...
Thread one = new Thread(new A());
Thread two = new Thread(new A().new B());
...


One important detail: In this code, threads "one" and "two" each use a different instance of A. So if obtaining the object lock for the instance of A prevents the method in B from running, then we would not see it here.

If you change this detail, then I think the code will demonstrate what you intend.
[ September 26, 2007: Message edited by: marc weber ]
 
ahmed yehia
Ranch Hand
Posts: 424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Marc, now how about this code:

Note with this modify code in A still doesnt block code in B

[ September 26, 2007: Message edited by: Ahmed Yehia ]
[ September 26, 2007: Message edited by: Ahmed Yehia ]
 
marc weber
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ahmed Yehia:
...with this modify code in A still doesnt block code in B...


Looks good to me!

"obj" represents an instance of A, and the thread invoking methodA must obtain that object lock. "obj2" represents an instance of A.B, and the thread invoking methodB must obtain that object lock. I think this code demonstrates these are different locks.
 
marc weber
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's another detail that's worth thinking about: Joshua's original post says, "Class A has a reference to Class B," which I took to mean A HAS-A B, so I made this an instance variable and used it to access the instance of the inner class.

Also, rather than making A and B Runnables, I created entirely separate threads that both use the same instance of A. Also, I used sleep rather than yield (as an added incentive for the thread scheduler to split CPU time between the threads).

 
ahmed yehia
Ranch Hand
Posts: 424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thats well demonstration, also by creating anonymous threads we keep the code clean, have been thinking about that So now its clear that inner classes and their enclosing classes have entirely different monitors.
 
Don't listen to Steve. Just read this tiny ad:
Garden Master Course kickstarter
https://coderanch.com/t/754577/Garden-Master-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic