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 on synchronize block Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Question on synchronize block" Watch "Question on synchronize block" New topic
Author

Question on synchronize block

Shashank Gokhale
Ranch Hand

Joined: Jan 07, 2003
Posts: 92
Hello,
Im reading through some synchronize literature and I came across this and I am confused.
In the following example

I understand that since the method call() in the class Callme is not declared synchronized, it can get called randomly by each of the three threads, and therefore the output will not be
[Hello]
[Synchronized]
[World]
but rather is
[Hello[Synchronized[World]
]
]
If I declare the method call() to be synchronized as in the following,

then the output is
[Hello]
[Synchronized]
[World]

The author Jyothi also goes on to say that in the aller class' run method, I can also enclose the target.call(msg) method in a synchronized block as in the following


The output is the same whether I enclose the target.call(msg) in a synchronized block or not. So what is the purpose of using a synchronized block, as used around the target.call(msg) method?

[ February 12, 2003: Message edited by: Shashank Gokhale ]

May the force of the Java be in all of us !!!
Ellen Zhao
Ranch Hand

Joined: Sep 17, 2002
Posts: 581
When you synchronize a method, the object used to invoke the method is the object whose lock must be acquired. In your case, the object is target. But when you synchronize a block of code, you specify which object's lock you want to use as the lock( in your case: target ), so you could, for example, use some thrid-party object as the lock for this piece of code. That gives you the ability to have more than one lock for code snchronisation within a single object. In your example, a synchronized method is fine enough, you don't really need to do fancier stuff to accomplish the goal of this program. I guess the author put the syncronized block here for some pedagogic purpose -- to show variations of synchronisation.

Regards,
Ellen
Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
Well, while it may have been the same for you that doesn't mean the extra synchronized block doesn't help. A few things:
1. Every OS implements Threads a bit differently. So on some OS's, it's possible that no matter what, all your threads are going to be of the same priority and get an equal amount of CPU time. This could account for the perfect synch. Java cannot do anything about this, as the Thread class is just a representative of the underlying threads in native code.
2. I would reccomend against using both synchronized blocks, since it amounts to nested blocks (not good - ripe for deadlocks). I think the author may have meant it to be an either/or. But sample code in books is frequently buggy.
Shashank Gokhale
Ranch Hand

Joined: Jan 07, 2003
Posts: 92
Ellen,
Okay, I think I understand what youre saying. What I understand is that if I had another that I wanted to be the controlling thread that would decide how to synchronize a program, then I could use that to obtain a lock.
So,
if I had a thread called t1, and I wanted to synchronize the handling of other threads, I could say something like
synchronize(t1)
{
synchedthreads.runThreads();
}
where synchedthreads is an object that has several threads running together. Am I coorect in my understanding?
Robert,
What you said is that I shouldnt synchronize use both the block and the method because this could lead to deadlock between the threads. Why would this happen? Earllier in your post you said the following:

If the synchronize block is helpful according to what you said, wouldnt the fact that using both a synchronized block along with a synchronize method still cause deadlocks? In that case, I guess the better thing to do is to always use synchronize blocks and not synchronize methods. Is what Im saying true?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Question on synchronize block