threading single instance vs multiple instances

[Gurukeerthi Gurunathan]

Group,

Assume a class

  
public class MyClass implements Runnable{
public MyClass(){}
public void run(){
// some operation here
}
}

Can someone clarify the difference(if any) between these two approaches in multi threading? Which one is indeed multithreading?

Approach 1. I instantiate two objects

  
MyClass obj1 = new MyClass();
MyClass obj2 = new MyClass();
Thread t1 = new Thread(obj1);
Thread t2 = new Thread(obj2);
t1.start();
t2.start();

Approach 1. I instantiate one object

  
MyClass obj1 = new MyClass();
Thread t1 = new Thread(obj1);
Thread t2 = new Thread(obj1);
t1.start();
t2.start();

[J Williams]

I'll give the answer a shot.
For sync to work, the threads in question must be accessing the same object. So in the example where you create two different instances of MyClass, you have two seperate objects and sync will not happen. The example you give where you create one object and start two threads is the correct example. Of course, you must still have a syncronized block of code, but I assume you realize that.

[Stan James]

That's a very concise example to get to this discussion. When you make two objects and put them on two threads, each instance only has to work on a single thread. That's the easy way to do things - a "non-threadsafe" approach.

When you run two threads with the same instance of your runnable the JVM is allowed to run one line of code for thread 1 and another line of code for thrad 2, and can even break up parts of lines. So if you do something as simple as:

public void doSomething(int i)
{
   memberVar = i;
   if (memberVar == i) ...
}

you can be surprised to find that another thread changed memberVar to 437 in between those lines. If you know a class will be used this way, or you want to make it possible, you have to make it thread safe.

You have to think about any resources that might be shared by two threads in the same object instance. Member variables, any other external objects that both threads might reference, etc. It's likely you'll want to synchronize methods or code blocks (prefer code blocks) that access such shared resources.

If each thread needs its own variables or resources or whatever, make them as local variables. Each thread gets its own set of local variables on the stack.

Any of that make sense?

[Gurukeerthi Gurunathan]

Thanks Stan - that's what I thought. In Approach 1 where I have two objects how does the control flow? Let's say I have that code in the main method of a class called MainClass. After I do the t1.start(), does the main thread returns immdtly to the next line t2.start() without waiting for the t1's run method to finish? Assuming I have no code to share between them and I am taking approach 1, if main method doesn't wait on the t1's thread to finish and goes to the next line, it'll look like multi threading to me...

Guru.

[Stan James]

The main thread will start up T1 and then start up T2. You have no guarantees about whether T1 will actually execute any statements before T2 or not. If they both run a while and do some operations that yield the CPU, the JVM can interleave the execution ... a few instructions from T1, a few from T2, a few from T1 and so on. Meanwhile the main thread is free to go do other things and even exit. If you need to bring things together at the end, say to present the result of a parallel calculation, look into Thread.join().