synchronised code or block???

[srijan sharma]

hi all,
i read in a book that sometimes synchronisation(method) even does
not solve the concurrency problem and we have to use a synchronised block or wait in a sync. block with a boolean variable...
what is this all about. kindly explain with a small example the differnce between a sync blosk and snyc code..
regards
srijan

[George Toronto]

Originally posted by srijan sharma:
hi all,
i read in a book that sometimes synchronisation(method) even does
not solve the concurrency problem and we have to use a synchronised block or wait in a sync. block with a boolean variable...
what is this all about. kindly explain with a small example the differnce between a sync blosk and snyc code..
regards
srijan

Hi, srijan
Could you give me the original statement? Actually, the sync. block is more flexible than sync. method because the former can put thread into different objects in the same method. Thread calling sync. method just can enter monitor of the object where the sync method exists.
I am not sure what your statement means, however, I actually hear about the famouse "philosopher problem" which said a question caused by sychronization method, Maybe that can help you to understand the hi-level sychronization. did u know that?
regards
George

[This message has been edited by George Toronto (edited January 30, 2001).]

[Rahul Mahindrakar]

Hi srijan sharma,
Basically there are two ways one can obtain a lock on an object. The first is the "synchronized method" and another is the "synchronized block".
Part I
The synchronized method is declared for an instance or a static block as following
Example I

public class temp{
public void synchronized x(){}
public void synchronized x1(){}
public static void synchronized y(){}
public static void synchronized y1(){}
}

In the case of x & x1 method the lock on the instance is obtained.
In the case of y & y1 the lock on the class of temp is obtained.
What does this lock mean??
The lock on an instance method like x means that while a thread is in the x method no other thread can enter the x1 method too. Similar is the case for the y and the y1 methods.
The synchronized method in case of the instance locks the Object that is associated with "this". In the case of the static synchronized method a lock on the Class associated with temp is obtained.
Part II
There is another way to lock Objects. This is with the "synchronized Block"
The synchronized block is declared for an instance or a static block as following
Example II

public class temp{
public void x(){
synchronized(this){
// put your code here
}
}
public void x1(){
synchronized(this){
// put your code here
}

}

public static void  y(){
synchronized(temp.Class){

// put your code here
}

}
public static void y1(){
synchronized(temp.class){
// put your code here
}

}

}

The Examples I & II both undertake the same functionality. There may be some reasons why one can opt for the Example II model rather than the Example I model. This is to put all non synchronized code outside the method block and then use the synchronized block when it is really needed like this

public void  x1(){
// some work not needing synchronization is done here

synchronized(this){
// put your code here
}

}

However the synchronized method cannot be used when i want to lock an Object not associated with the current instance - "this" or the current class " temp.Class". In this scenario i need to use the synchronized block.
Example II

public class temp{
xyz locked=new xyz();
public void x(){
synchronized(locked){
// put your code here
}
}
public void x1(){
synchronized(locked){
// put your code here
}

}

public static void  y(){
synchronized(xyz.Class){

// put your code here
}

}
public static void y1(){
synchronized(xyz.class){
// put your code here
}

}

}
class xyz{
}

Hope things are clear. If anything is unclear do get back.
Regds
Rahul P. Mahindrakar

[srijan sharma]

thanks rahul,
but i wanted a real multithreaded example where i can understand real importance of both synch. block and synch. methods..
or suggest some cool links ..
regards
srijan

[Rahul Mahindrakar]

check out a few resources here

[George Toronto]

hi, Rahul
It is a good statement for the basic concepts for sychronization, but srijan's question is not still solved.
Actually, sychronization solve the concurrency question, but it has two problems.
1) sychronizing each methods in a class is a bad idea, If it is done, the multithread machanism does not exist. Right? So sychronization should be applied in the appriciate situation.
2) the "philosopher problem" still exists in Java multithread mechanism and is also caused by the sychronization. the prolem can be descripted as the following: 5 philosapher is sitting around a tale and wanna eat their dinner, but there are only 5 chop sticks at the table(you know, if they wanna eat at the same time, there have to be 10 chop sticks at the table). So they have to share the chop sticks, that is, only 2 philosophers can eat together and others have to wait.( of coz, they are stupid enough not to know go to kichen and bring other 5 chop sticks ). That means the sychronization cannot slove the concurrent prolem.
That is just my undertanding. Plz correct them if I make mistakes.
rgds
George
[This message has been edited by George Toronto (edited January 30, 2001).
[This message has been edited by George Toronto (edited January 30, 2001).]