aspose file tools*
The moose likes Java in General and the fly likes Single Object Concept in synchronization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Single Object Concept in synchronization" Watch "Single Object Concept in synchronization" New topic
Author

Single Object Concept in synchronization

Ravissant Markandey
Ranch Hand

Joined: Oct 24, 2007
Posts: 41
Hi everyone, My doubt relates to the "single object" concept talked about in synchronisation. We know that two threads can conflict only when the "runnable instance" is the same (Please correct me if im wrong, this has been my understanding so far.) , for example:


Now Threads a and b above have the same runnable instance mt, and its precisely because of this ONE runnable instance that the entire concept of "thread conflict" and "synchronization" comes about...once again plaease correct me if Im wrong.

Now what I want to ask is, how do you get a single runnable instance when you extend the thread class, as in :


So in the code above do we have a SINGLE runnable instance? If not then how do we do it when we extend the Thread class?

Please Help.

Thanks in advance,
Ravissant Markenday
Ulrika Tingle
Ranch Hand

Joined: Nov 24, 2009
Posts: 92
Ravissant Markandey wrote:We know that two threads can conflict only when the "runnable instance" is the same (Please correct me if im wrong, this has been my understanding so far.)


I think this view is too limited. Thread conflicts do not happen only when two threads execute the same run() method of an object implementing Runnable. It can happen anytime when several threads operate on shared data. But there definately is a possible threading conflict in your first example (because two threads execute the same method in the same object).


So in the code above do we have a SINGLE runnable instance? If not then how do we do it when we extend the Thread class?


In the second example your code must be changed to,

Thread t1=new MyThread(); // instantiate a MyThread object, not Thread
Thread t2= new MyThread();

to be meaningfull. Otherwise the run() method of MyThread won't be called at all. But maybe it was a typo?

Anyway the difference is that each thread object will call its own run() method so there's no chance of any threading conflics here. To re-establish the situation from the first example you need to do,

Thread t1=new MyThread();
Thread t2= new MyThread(t1);

The t1 thread will execute the run() method of one MyThread object. This object will then also be passed as a Runnable object (possible because Thread implements Runnable) to the t2 thread which will execute the run() method of the passed in object. So both threads now execute the same run method and you once again have a possible threading conflict on your hands.
Ravissant Markandey
Ranch Hand

Joined: Oct 24, 2007
Posts: 41
Thanks Ulrika, that was amazingly detailed.Thanks once again
Ulrika Tingle
Ranch Hand

Joined: Nov 24, 2009
Posts: 92
Ravissant Markandey wrote:Thanks Ulrika, that was amazingly detailed.Thanks once again


You're wellcome.

The Thread class is somewhat confusing in that it offers two different ways to run your code in separate threads. Each way is modelled after a different so called design pattern. The first, when you pass in a Runnable object to Thread, is called the Strategy pattern. The second, when you extend Thread and override the run method, is called the Template Method pattern.

Thread implements both Strategy and Template Method so you need to make a choise. I think Strategy should be considered the preferred way. At least it seems most popular. The reason is that the class inheritance used in Template Method leads to a more static, less flexible solution.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Single Object Concept in synchronization