This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
As an example, let's say you are developing a thread-safe queue class. You have a write method that puts an object into the queue, and a read method that takes an object out. Both methods adjust indexes, the object count, and possibly even reorder the elements in the case of a priority queue. OK, a reader thread calls the read method, but the read method finds that the queue is empty. It wants to tell the thread that it should wait for something to be written. The read method is synchronized, so it just needs to include the line: wait(); If the wait method was on the thread class, it would be necessary to write: Thread.currentThread().wait(); Which way is easier? Wait, it gets worse. A writer thread comes in and writes an object to the queue. When it's done, it wants to notify any readers waiting for on empty queue that it's time to get busy reading. Therefore the write() method contains the line: notify(); (Actually, notifyAll() is safer since I haven't distinguished between waiting readers and waiting writers.) If notify was a method in the thread class, the code would be: Thread.getFirstThreadWaitingFor(this).notify(); I'm not even sure how notifyAll() could be implmented. It obviously couldn't be a call on an individual thread. So you can see, even though wait() and notify() seem to be methods affecting threads, it is much easier to write code when they are part of the Object class.
... Or, to say it shorter: Locking a chunk code doesn't really gain you anything. Code exists to manipulate objects. So what you really are trying to do is regulate changes to the objects. The finer degree of control you can have on locking, the less time your apps will be spent hung up on waiting. So if you lock only the object(s) of interest, other threads can continue on, even possibly using that same code, but on different objects.
Customer surveys are for companies who didn't pay proper attention to begin with.
Because you lock with respect to a certain object, not a certain thread. Locks give you safe access to an "object", so locks have to work with the object. A thread is not an object, but an execution point. Notwithstanding, a "Thread" (with a capital T) is a class which can be an object, its only used to communicate with and represent in some respects, the underlying "thread" (with a lower case t).