1) "last but not the least, the dead thread can be restarted
by creating an instance of Thread and passing the dead object as
the target to the constructor. Remember this may/may not be prudent
especially when your class has some computed state information. "
is this right please varify this with an example Yes, this is correct. The passage you've identified assumes that the Object with the run() method whose code you want to executes implements Runnable, rather than extending Thread (that is, the object that you want to run in a new thread is not the actual Thread object, but is a Runnable object passed to a Thread.) Once the thread that you've created is dead, that's it for that Thread. However, you can create a new Thread and pass it the same Runnable object, then run that new Thread.
An example? Here:
<pre>
class DoSomething implements Runnable {
public void run() {
// important code goes here
}
}
class StartManyThreads {
public static void main(
String[] args) {
DoSomething ds = new DoSomething();
// we just instantiated a class that implements Runnable
Thread t = new Thread(ds);
// we just created a Thread and passed it
// our Runnable instance
t.start(); // important stuff happens, then t dies
Thread t2 = new Thread(ds);
// our ds instance still lives on, so we can
// create a brand new Thread, and pass that Thread the
// same old ds instance
t2.start(); // ds's code runs again in a new Thread
}
}
</pre>
2)Each object has only one lock...
2)A unique monitor is associated with every object that has a
synchronized method...
the abpove 2 points seems contradicting to me b'coa according to second poiunt
if each object have its unique lock then at a time both the method can
be holding there own lock but second poiunt says that no thread can enter
any of the synchronized method until the first exits the mthod it was executing and frees
the lock."
now suppose we have a synchronized mthod fn()
and there are 2 different objects of the class in which fn() is
present ob1 and ob2 now both of these have there seperate monitors then at a time kboth can execute there seperate fn()
but I think this is wrong according to the I point
ps anyone clear this thing to me with a good example ( preferably a working program) I have no working code right now, but I see the part that you are missing. Synchronized methods are placed in Objects that may have many different Threads affecting them.
Let's say that we have one instance of an Object called DataStorage, which stores lots of mission-critical data. Then we have, say, five instances of a class called DataManipulator, all in their own Threads, whose job it is to modify the data stored in DataStorage. Your assumption is that the synchronized methods would be in the DataManipulator class. Wrong. That wouldn't do much good. The synchronized methods should be put in the DataStorage class. Here's why:
Say the DataStorage class has a lengthy method called ManipulateAllData(). It's very likely that one DataManipulator thread could begin calling that method on the DataStorage instance, but then another thread would overtake it. This is where data corruption would occur. If ManipulateAllData() was syncrhonized, then the first
DataManipulator thread to enter that method would hold the lock belonging to the
DataStorage instance. Thus, as long as that DataManipulator thread is executing that method, no other threads of any kind can call that method.
The last point is, now, let's say there is another method in the DataStorage class called ManipulateSomeData(). If that method is also syncrhonized, then no other thread can call
that method, either, while the first thread is executing ManipulateAllData(). That's because the two methods are both synchronized to the Data Storage object.
Hope that helps somewhat.
3) static methods can be synchronized, and static methods use the lock belonging to the class rather than a lock belonging to any particular object.
now what does this mean in context with the above arguement??? It really just refers to the object that the method synchronizes to. If you are completely new to locks and synchronization,
you should do a little reading before this all makes sense. Otherwise, that statement is simply stating that a <code>static synchronized</code> method will usethe lock belonging to the
class object, whereas a non-static <code>synchronized</code> method will use the lock belonging to an instance of that method.
4) what is the difference b\w sleep(milliseond) and wait(millisecond) sleep(millisecond) 1. it's a static method in <code>Thread</code>; 2. it simply tells the currently executing thread to pause for the given # of milliseconds, then try to resume running.
wait(millisecond) 1. it's a method in <code>Object</code>; 2. it can only be called in a <code>synchronized</code> method, where the current thread holds the lock of the object that contains the synchronized method; 3. it causes the current thread to release the lock, and then stop executing. It will not execute until some
other thread calls <code>notify()</code> within the that object that contains the synchronized method.
So in sum, sleep() is more simple; it can be called at any point, and it just causes the current thread to pause for at least the given amount of time. wait() may only be called from within a <code>synchronized</code> method, and depends on another thread calling <code>notify()</code> for it to ever resume running.
