An Object's thread of execution

[John Wright]

Can someone explain to me how an object knows what thread of execution to run in. If a thread of execution is basically a method stack (is it?) and I start 2 method stacks at the same time by kicking off a thread from one object, then the second thread will start its execution in the method "run" of its target object, correct? Let's say this second thread is a server thread and inside run it goes into an infinite loop waiting for invocations. I don't understand how another object can invoke methods on it when it is inside the run method executing in an infinite loop. I guess I don't understand the relationship between objects and threads.

[John Wright]

After thinking about this I want to clarify this question furthur. Every Thread object starts execution in its run method. If it is executing inside run how can another object call other methods on it and if they do what thread of execution will those methods operate in?

[Ryan Langley]

Hello,
From your questions I think that basically you are asking that if you have an object, say object A for example, you want to know if two threads, say thread B and thread C, can access it at the same time. This is possible, but it may not be a good thing. If you know that the methods on A that will be called by B are methods that are never called on A by C then you won't have any problems. BUT if both threads are accessing the same methods in the object, then you will have to synchronize those methods to make sure that the threads don't execute on it at the same time. When the methods are synchronized, a thread will lock the object while it executes within it so that any threads that attempt to access the object while it's locked will enter the wait state. Then, when the thread exites the synchronized method, the waiting thread(s) will then attempt to access the object again. When one obtains a lock, the others will again wait for it to free up before continuing. Hope this helps in answering your question!
Cheers,
RL

[John Wright]

Ryan,
That does help. I have done a lot of research on this today and I think I have a distinction to offer that would help others who stuggle with the relationships between objects and threads. Junior Java programmers like me might assume that just because an object has the type Thread then all of its methods will run in a seperate thread. This is not so of course because only methods that have a method stack starting from the method run will execute in a seperate thread (once run is called of course). Objects in fact don't run in threads, methods do something I was reminded of in the following link:
http://www.holub.com/javaone/holub_threads.pdf
A thread in Java is therefore a sequence of method calls on essentially passive objects that just have state. The methods change the state of those objects. Two sequences of methods calls can be running at the same time (two threads) and try to change the state of an object at the same time. As Ryan pointed, it is necessary to lock the object so that the resulting state of the object is determinate. Any object can call a method on another object and each does within a particular thread (sequence of method calls). My confusion in my original post was to think that just because an object was of type Thread and executing within its run method it could not have another method (like push() ) called on it. It of course could; this other method call would simply occur in another thread of execution.
This might help some people to understand how servers who assign threads to handle requests can be invoked by clients. The server often goes into an infinite loop inside waiting for requests. When a request comes in it kicks off a thread to execute the request. Inside the run method of that thread the server object will service the request freeing up the parent server to assign other requests to other server threads. Each server thread should have the information it needs to return results back to its caller.