aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Synchronization related query... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Synchronization related query..." Watch "Synchronization related query..." New topic
Author

Synchronization related query...

Tanya Shetty
Ranch Hand

Joined: Jun 17, 2009
Posts: 40
Hi,

I have a question regarding synchronization block ..

e.g.
method ()
{
synchronize(third party object)
{

update third party object
update "this" object
update another object ...

Method();

}
}

Does this synchronize block , provide a lock on all three objects iei "third party", "this" and "anothr object" or only "third party object".

If it provides only lock for "third party" then any other method which updates "this" object from a non-synchronized method is eligible for modification ?

Is the code within Method() ie object within Method() if any, are also locked by this synchronization block ?

Apologies if this Q has been answered before .. i am relatively new to this topic myself..hence, if any useful links for more details on synchronization and threads, please do post it for reference...

Thanks a ton!

Tanya

Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18990
    
  40

Does this synchronize block , provide a lock on all three objects iei "third party", "this" and "anothr object" or only "third party object".


Only the objects that you synchronized will be used as a lock -- there is no magic mechanism that figures out what else to lock.

If it provides only lock for "third party" then any other method which updates "this" object from a non-synchronized method is eligible for modification ?


Synchronization is completely cooperative. For example, if another thread decide to access the "third party" object without synchronizing on it, it can break your app too. There is no magic mechanism that prevents threads that refuse to cooperative to be locked out too.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18990
    
  40

Is the code within Method() ie object within Method() if any, are also locked by this synchronization block ?


As for this... I read this three or four times, and I don't know what you are asking...

Henry
Jason Irwin
Ranch Hand

Joined: Jun 09, 2009
Posts: 327
The lock is only held on the object stated in the "synchronize" statement, that would be "third party object" in your example. It you want to hold more locks, you need more "synchronize" statements.

The lock is held for the entire duration of the block, and that includes all methods that may be called from within it.

You also want to be careful with your code - you are one letter away from a recursive call and a stack overflow!

Please use code tags in the future.


SCJP6
Tanya Shetty
Ranch Hand

Joined: Jun 17, 2009
Posts: 40


Output -


Here in the above eg, meth1() synchronizes a block on "this" reference, ONLY THIS OBJECT ie current ObjectLocking instance IS SYNCHRONIZED, NOT OBJECT OutsideObject , am i right ?

Since, meth2() is not synchronized nor had any synchronization blocks... any thread which does NOT have lock on "this" object(current ObjectLocking instance) can be invoke this meth2()... right ? , if picked y thread scheduler, of course ...

In this case, if it is picked by the scheduler, will this thread be able to modify the "Outsider Object", since it is the same object passed to meth1() and meth2() but has no synchronization lock on it?

Also, will it be able to update instance variable "x", my assumption is NO, if a thread might have a lock on "this" instance, ie current instance of ObjectLocking, then it will not be able to acess the "x" on the current object from "objectLocking" ?

If you do have some basic rules for synchronization which you think i am missing out on, could you please share it , thanks for the help!

Tanya

Jason Irwin
Ranch Hand

Joined: Jun 09, 2009
Posts: 327
Yes, you are correct about what is being locked on.

Meth2 is not synchronized, any other thread can call it at any time. Even if meth2 has been called from synchronized code (say, meth1 for example), any other thread can still call meth2 any any time. In a nutshell, your code is not thread-safe.

Meth2 will be able to change x - why wouldn't it? x is in scope.

You could simply place a synchronized block inside meth2 (or declare the method synchronized), that would stop it updating x at the same time meth1 is running, but that may not be enough. It would still be possible for another thread to interfere between calls to meth1 and meth2. If that is a concern in your design, you should place the calls to meth1 and meth2 inside a synchronized block as well.

Threading can be tricky to get right - the only thing to do is practice, practice, practice. And don't forget about wait(), notify() and notifyAll().

The K&B book has a good section on threading.
Tanya Shetty
Ranch Hand

Joined: Jun 17, 2009
Posts: 40
Thank you very much Jason and Henry.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Synchronization related query...