jQuery in Action, 2nd edition*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes locks and monitor Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "locks and monitor" Watch "locks and monitor" New topic
Author

locks and monitor

devesh singh
Greenhorn

Joined: May 08, 2001
Posts: 9
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

2)Each object has only one lock. Therefore, if an object has three
synchronized methods, a thread entering any of the methods will set
the lock. After that, no thread can enter any of the synchronized
methods until the first exits the method it was executing and frees
the 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)
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???
4) what is the difference b\w sleep(milliseond) and wait(millisecond)
dave taubler
Ranch Hand

Joined: May 15, 2001
Posts: 132
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.

Dave Taubler<br />Specializing in <a href="http://taubler.com/articles/" target="_blank" rel="nofollow">Java and Web Development</a>
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: locks and monitor
 
Similar Threads
Thread Synchronization
Wait and Notify
unlock method
Thread.yield vs sleep
Synchronized blocks