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.