Hi, Can construtor be synchronized True/false (False) 2) I have doubt with the following code .
In the above code we are starting thread with same target. Am not getting that point. If we make the run method as synchronized, the out put is differnt. I want to know when t1.start() call synchroinzed run method, the lock is with the object of Account class. am i right, which in turn will be with t1. So t2 cannot start the run method. Is this correct or not. Can any one explain me. Thanks in advance
Arathi<br />Sun Certified Java Programmer
Joined: May 10, 2001
Originally posted by Arathi Rajashekar: I want to know when t1.start() call synchroinzed run method, the lock is with the object of Account class. am i right, which in turn will be with t1. So t2 cannot start the run method. Is this correct or not. Can any one explain me. Thanks in advance
Arathi You are partially correct. when you create a thread that has a Runnable object as its target it is the Runnable objects run method that gets called. In your example the class that implements Runnable is the AccountDemo class. If you make the run method synchronized and then call start with the same target it the target object whose lock must be obtained to run. In your case if you synchronize the run method the second thread can not start executing until the first one gives up the lock. The yield you have in the run method would have no effect if the run method were synchronized because #1, there is no other thread to yield to, and, #2, yield does not give up the lock on an object so the other thread would never be given a chance to start. Hope that helps
Joined: Nov 04, 2001
hi arthi, y constructor need b synchronized??? it's object we need to share and if we need to share class we have locks for static methods etc... construtor spawns/creates new object. so what point would be make making constructor synchronized? it has to be 'false' regards maulin.
To the question given, the answer is no. Constructors cannot be synchronized, abstract, native, final, or static. You wouldn't want to, anyway. It's a bad choice, and if the design of your code leads you there, it's a good indication your problems have already been written into the code. I can imagine a few cases where a synchronized constructor would make sense, but only for hacking past an issue when fixing it would be the right thing to do. The candidates for synchronization in this code are the deposit() and withdraw() methods. It's these methods that should protect the so-called critical data since they allow manipulation of its state. Dave points out that Thread.yield() doesn't do what you want. To that I add, what you want to do isn't what you want to do, either. :roll: That is, you don't want Thread behavior to protect your data, you want object behavior, in the form of the wait() and notify() methods, to do that. Take a look at them and see if you don't agree. [ January 10, 2002: Message edited by: Michael Ernest ]
Make visible what, without you, might perhaps never have been seen. - Robert Bresson