File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Question about synchronized Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Question about synchronized" Watch "Question about synchronized" New topic
Author

Question about synchronized

George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Hello everyone,


Suppose I have a method which is a synchronized method (for example, method Foo in the following code block), and in this synchronized method another method which is not synchronized is invoked (for example, method Goo in the following code block). I am wondering when executing in Goo from Foo, whether we still have the synchronized feature (i.e. obtain the lock of "this" object).




Thanks in advance,
George
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Perhaps this is a little nit-picky, but your methods are missing return types. Also, methods should start with lower-case. Typically only class names and the corresponding constructors start with upper-case.

Of course, that doesn't answer your question. AFAIK, the object that was used to call the Foo() method is still locked. The lock is not released until after Foo() returns, which will only happen after Goo() returns as well.

Layne


Java API Documentation
The Java Tutorial
Stephen Huey
Ranch Hand

Joined: Jul 15, 2003
Posts: 618
If Goo isn't called from anywhere else, then I don't think anyone can get to it without already having access to your synchronized method.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Moving to "Threads and Synchronization"...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

Hi George,
We meet again :-)
An excellent question again from you :-), not one many people would have given much thought to, unless they happen to come across some specific question like the one you have posted.
Logically, atleast superficially, it would look true that when a synchronized method calls a non-sync one, the lock obtained on the former would extend to the latter. But lets for a moment continue this logical thinking process (Its good only when u take it to a conclusion, not abandon it half way ;-)).
How does the jvm know all methods which are being called from the former (sync-ed one). No way, right ? So assuming that our initial reaction to this is correct ,ie a lock on a sync-ed method extends to all methods being called from it, then the jvm (bcos it has no means of knowing until runtime the method calls from a sync method) has to lock all the methods in a class that has atleast one sync method.
What this would mean is that the effect of sync-ing one method would be equal to sync-ing all the methods bcos any of the other methods could be potentially called from the sync-ed one.
This would be hazardous to say the least and synchronization would be a leper for java programmers then :-)), nobody for obvious reasons would touch it.
The example below is co-erced, but serves to illustrate the point.



And the o/p I got was

Th one accessing goo/*thread one in goo, is in wait() coz of the funny if clause there*/
Th two accessing goo /*there's no lock on goo, else with thread one in wait(), this wouldve been impossible*/
Th two returning from goo/*Thread 2 is over with Goo(), will go back and notify Thread 1*/
Th one returning from goo/*Thread 1 is notified, wakes up and returns :-)*/

Hope this helped.

Tx,
Ram.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18108
    
  39

And the o/p I got was

Th one accessing goo/*thread one in goo, is in wait() coz of the funny if clause there*/
Th two accessing goo /*there's no lock on goo, else with thread one in wait(), this wouldve been impossible*/
Th two returning from goo/*Thread 2 is over with Goo(), will go back and notify Thread 1*/
Th one returning from goo/*Thread 1 is notified, wakes up and returns :-)*/



I am not exactly sure what the discussion example was about, and how it applies to the original question... but...

-- A synchronized method does not give up its lock when it calls a non-synchronzied method. The lock is still held while the non-synchronized method is being executed.

-- Synchronized methods are allowed to "nest" -- meaning the JVM will allow the owner of a lock to grab it again, and will keep track of how many times it is grabbed.

-- A call to the wait() method will release the lock that it is waiting on. It will be released the amount of times that it has been grabbed.

-- Upon return from wait() method it will reacquire the lock. Again, it will grab it as many times as it has been released.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Layne,


Originally posted by Layne Lund:
Perhaps this is a little nit-picky, but your methods are missing return types. Also, methods should start with lower-case. Typically only class names and the corresponding constructors start with upper-case.

Of course, that doesn't answer your question. AFAIK, the object that was used to call the Foo() method is still locked. The lock is not released until after Foo() returns, which will only happen after Goo() returns as well.

Layne


Both your advices and your reply to my question are very helpful.


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks ramprasad,


Your great answer and sample are very helpful. I think you are a real expert.


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Henry,


Originally posted by Henry Wong:


I am not exactly sure what the discussion example was about, and how it applies to the original question... but...

-- A synchronized method does not give up its lock when it calls a non-synchronzied method. The lock is still held while the non-synchronized method is being executed.

-- Synchronized methods are allowed to "nest" -- meaning the JVM will allow the owner of a lock to grab it again, and will keep track of how many times it is grabbed.

-- A call to the wait() method will release the lock that it is waiting on. It will be released the amount of times that it has been grabbed.

-- Upon return from wait() method it will reacquire the lock. Again, it will grab it as many times as it has been released.

Henry


I am wondering why should amount of times that the lock has been grabbed be tracked. From your reply, I can not see what is the difference of grabbing a lock twice and grabbing a lock once.


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Ilja,


Originally posted by Ilja Preuss:
Moving to "Threads and Synchronization"...


I think "Threads and Synchronization" forum is more fit for my question.


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Stephen,


Originally posted by Stephen Huey:
If Goo isn't called from anywhere else, then I don't think anyone can get to it without already having access to your synchronized method.


Your reply is very helpful.


regards,
George
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18108
    
  39

Originally posted by George Lin:
I am wondering why should amount of times that the lock has been grabbed be tracked. From your reply, I can not see what is the difference of grabbing a lock twice and grabbing a lock once.

regards,
George


From your point of view, there is absolutely no difference. It is for the system to make sure it does it correctly. For example, when you leave a sychronized block or method, should the lock be released? Well, the answer is "it depends on whether you already had the lock when you entered". If the system doesn't keep a count, then how will it know?

If you are asking, "why would you want to grab a lock more than once?". There is no benefit to doing it. But if the system don't allow you to do it, then you won't be able to call a synchronized method from a synchronized method of the same instance... which is quite common.

Henry
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
It is a great answer, Henry!


Originally posted by Henry Wong:


From your point of view, there is absolutely no difference. It is for the system to make sure it does it correctly. For example, when you leave a sychronized block or method, should the lock be released? Well, the answer is "it depends on whether you already had the lock when you entered". If the system doesn't keep a count, then how will it know?

If you are asking, "why would you want to grab a lock more than once?". There is no benefit to doing it. But if the system don't allow you to do it, then you won't be able to call a synchronized method from a synchronized method of the same instance... which is quite common.

Henry



regards,
George
 
Consider Paul's rocket mass heater.
 
subject: Question about synchronized
 
Similar Threads
Synchronized blocks
Synchronozation
Synchronization and Locks
please help, about synchronized block
Checking for String value in this Collections.synchronizedSet(new HashSet()) ?