Synchronized methods
Doug
I was wondering why the code below doesn't block? Ie. as far as I see
it, the two dates should be printed with a 10 second interval between them?
import java.util.Date;
public class SyncExample {
private static Thingie thingie = new Thingie();
public static class Thingie {
private Date lastAccess;
public synchronized void setLastAccess(Date date){
this.lastAccess = date;
System.out.println(this.lastAccess);
try{
this.wait(10000);
}
catch (Exception e) {}
}
}
public static class ThreadOne extends Thread {
public void run(){
thingie.setLastAccess(new Date());
}
}
public static void main(String[] args){
new ThreadOne().start();
new ThreadOne().start();
}
}
Thanks :-)
Carl Howells
That's what happens when you don't understand the difference between
Object.wait(long) and Thread.sleep(long).
Thread.sleep just causes the calling thread to block for either the
specified time, or until it is interrupted.
Object.wait is much more complicated. First, it's an instance method,
not a static method. That means that the object it is called on matters
somehow.
What object is used matters because of Object.notify and
Object.notifyAll. Wait is intended, primarily, to function as half of a
signalling mechanism between threads. It is intended to block only
until either notify or notifyAll is called on the object it's waiting
on. However, in order for the inter-thread communication to work
correctly, both calls to wait and notify have to be synchronized on the
object they're being called on.
Obviously, there is a potential problem there... How is notify ever
going to execute if wait has to be executed in a synchronized block?
The solution is simple. Wait releases the monitor before it blocks the
current thread. And that's the behavior you're seeing.
In case you're curious, the full sequence for a wait-notify exchange
looks like this:
Thread A acquires lock for object O.
Thread A calls wait on object O.
Thread A releases lock on object O.
Thread A blocks.
Thread B acquires lock for object O.
Thread B calls notify (or notifyAll) on object O.
Thread B does whatever else is in its synchronized block.
Thread B releases the lock on Object O because it leaves the
synchronized block.
Thread A acquires the lock for object O.
Thread A resumes execution after the call to wait.
Pennac G
This is not exactly how it works. You are creating two differents thread
with two differents object monitor which had no meaning of each other and
actually, yes each threads "block" for 10 seconds.
Take a look at
http://java.sun.com/docs/books/tutorial/essential/threads/multithreaded.html
for more information on thread.
Doug wrote:
--
--
Pennac.
Robert Mark Bram
When one thread waits, it gives up the lock.. so the other can do its thing!
Rob
:)
:-}
;->
Doug
guess I'll have to grab a book soon enough), than it makes perfect sense
and it ...also works.
as the french say, merci
Witek Mozga
>When one thread waits, it gives up the lock.. so the other can do its thing!
I`m a newbie so please explain me one thing. When sleep(millisec) is
called on a thread it keeps its lock when sleeping, and when
wait(milisec) is called, the thread releases its lock. So why in order
to pause a thread everybody uses sleep(millisec). Wouldn`t
wait(millisec) be better for synchronized threads?
--
Witek
http://www.trimen.pl/witek/
Thomas Hawtin
>
> I`m a newbie so please explain me one thing. When sleep(millisec) is
> called on a thread it keeps its lock when sleeping, and when
> wait(milisec) is called, the thread releases its lock. So why in order
> to pause a thread everybody uses sleep(millisec). Wouldn`t
> wait(millisec) be better for synchronized threads?
Thread.sleep is mostly used for quick and dirty hacks. To indicate to a
sleeping thread that you want it to exit, say, you need to call
Thread.interrupt which isn't a particularly subtle thing to do.
The question of releasing locks is really here nor there. In general you
shouldn't call Thread.sleep with a lock held (or Object.wait with locks
on multiple objects).
Tackline
--
http://www.tackline.demon.co.uk/
Unemployed Java Developer of Central London.
Joona I Palaste
on comp.lang.java.programmer:
> Witek Mozga wrote:
>>
>> I`m a newbie so please explain me one thing. When sleep(millisec) is
>> called on a thread it keeps its lock when sleeping, and when
>> wait(milisec) is called, the thread releases its lock. So why in order
>> to pause a thread everybody uses sleep(millisec). Wouldn`t
>> wait(millisec) be better for synchronized threads?
> Thread.sleep is mostly used for quick and dirty hacks. To indicate to a
> sleeping thread that you want it to exit, say, you need to call
> Thread.interrupt which isn't a particularly subtle thing to do.
> The question of releasing locks is really here nor there. In general you
> shouldn't call Thread.sleep with a lock held (or Object.wait with locks
> on multiple objects).
Every time your thread needs to do something which can potentially take
a non-instantaneous time, such as wait for input, or wait for some time,
release every lock the thread holds. If they are needed after the non-
instantaneous operation, claim them back.
Making a thread wait while holding a lock is a very easy way to run into
deadlocks.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"It's time, it's time, it's time to dump the slime!"
- Dr. Dante