«

Chris Smith wrote:
> Thomas Hawtin <> wrote:
>
>>One subtlety I think worth pointing out is that wait releases the lock
>>(however many times), waits, and then reacquires the lock. notify and
>>notifyAll are different in that they do not release the lock.
>
>
> Neither notify nor notifyAll releases the lock, so I don't see how this
> is a difference. [...]

I believe Tom meant that there was a difference between wait() on the
one hand and notify() / notifyAll() on the other. At least, that's the
way I read it.

--
John Bollinger

John C. Bollinger <> wrote:
> I believe Tom meant that there was a difference between wait() on the
> one hand and notify() / notifyAll() on the other. At least, that's the
> way I read it.

Ah! That does solve some of the mystery. Of course, there are many,
many differences between wait and notify/notifyAll, since they do
entirely different -- close to opposite -- things. Still a little
confused, but it's time to drop it...

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

> Which statement of Thomas's did you want sample code for? Since they're
> statements about multithreading and its inherently nondeterministic
> nature, it would be tough to demonstrate either one with sample code.

Thomas suggested that the wait() call must be encapsulated in a loop
that checks for wakeup conditions. I am requesting a sample that shows
its usage over wait() thats not called from a loop.
--
VJ

vj <> wrote:
> Thomas suggested that the wait() call must be encapsulated in a loop
> that checks for wakeup conditions. I am requesting a sample that shows
> its usage over wait() thats not called from a loop.

Very precisely, the program must be written so that it behaves correctly
for a wait function that returns earlier the the next notify or
notifyAll. To put it in simple terms, imagine that Object.wait() were
implemented like this:

public void wait() throws InterruptedException
{
magicallyReleaseLock();
// don't really wait at all!
magicallyReacquireLock();
}

Would your code still work, except for any performance requirements? If
not, then your code is already broken.

Practically speaking, this always involves writing a loop. Just for
completeness sake, I'll point out that in theory you could actually use
recursion instead... but it would be a heck of a complicated mess.

I don't doubt that you saw broken sample code. Unfortunately, it
happens rather frequently.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Smith wrote:

[me:]
> > But using notify() is a good deal harder to get right. Tracking
> > /which/ thread needs to be notified is tricky what with race-conditions
> > etc.
>
> In fact, clearly it is ALWAYS a bug to use notify() whenever there could
> be heterogenous threads waiting on a single monitor. Why? Because you
> can't specify which thread to notify; so if you care (that is, if the
> threads do different things) then you've done something wrong.

This doesn't seem to make sense; am I missing your point, or did you mean
notifyAll() can't be used in such a situation ?


> > Anyway, with luck we shall soon all be able to forget that
> > wait()/notify()/notifyAll() ever existed, and leave the hard work to
> > Doug Lea and java.util.concurrency.*
>
> I'm rather skeptical about this. The new package certainly introduces
> tools for solving a few specific common concurrency problems, such as
> thread pools and the classic producer/consumer example. However, if I'm
> writing concurrent algorithms for matrix operations in a mathematical
> computing library, I don't think Doug's done much to help me out.

Point taken. But I don't think that concurrent matrix operations are a primary
use-case for less-than-highly skilled programmers. Come to that, I don't
immediately see a lot of need for complex wait-dances in such cases either, not
more than can be handled by the handshake primitives (Barrier, Latch,
Semaphore) that are in there already. But then, I have never paid much
attention to concurrent [array] algorithms, nor really used j.u.c.* yet, so I
may be missing much.

BTW, do you do a lot of concurrent number crunching at DesignACourse ?

-- chris

vj wrote:
>>Which statement of Thomas's did you want sample code for? Since they're
>>statements about multithreading and its inherently nondeterministic
>>nature, it would be tough to demonstrate either one with sample code.
>
>
> Thomas suggested that the wait() call must be encapsulated in a loop
> that checks for wakeup conditions. I am requesting a sample that shows
> its usage over wait() thats not called from a loop.

Open the src.zip in your JDK, if you have not already done so. Look at
java.awt.EventQueue.invokeAndWait (not invokeLater).

http://bugs.sun.com/bugdatabase/view...bug_id=4974934

With the "clarification" in 1.5 this code, although it does work on
Sun's JVM, is not safe in general. Unfortunately it is in a place where
it seems likely people will look for an example. The reason it works,
assuming no spurious wakeups, is related to the waiter lying in the
synchronised block throughout the multi-threaded life-cycle (and that
notifies do not release locks, making them different to how wait
operates in this respect).


I got an e-mail from the responsible engineer this morning. It will be
fixed with a change to a public API (although I have demonstrated a fix
without). Unfortunately it's too late for a public API change in that
area for Mustang, so it'll be in 7.0 (due 2008, IIRC).

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

[mallikk]

Please do help me in understanding why notify() is sending notification to all waiting threads.

Many thanks in advance.

CODE:

------
// reader class

class Reader extends Thread
{
Caliculator calc;

public Reader (Caliculator c)
{
calc = c;
}

public void run()
{
synchronized(calc)
{
try
{
System.out.println(Thread.currentThread().getName( ) + " is waiting ....");
calc.wait();
System.out.println(Thread.currentThread().getName( ) + " got notified ..");
System.out.println(Thread.currentThread().getName( ) + " - total : " + calc.sum);

}
catch(InterruptedException ie) {}
}

}

public static void main(String [] args)
{
Caliculator cal = new Caliculator();
Reader r1 = new Reader(cal);
r1.setName("Reader-1");
Reader r2 = new Reader(cal);
r2.setName("Reader-2");
Reader r3 = new Reader(cal);
r3.setName("Reader-3");

cal.start();
r1.start();
r2.start();
r3.start();



System.out.println("Program ends here");
}
}

//caliculator class

class Caliculator extends Thread
{
int sum=0;
public void run()
{
synchronized(this)
{
for (int index=0;index < 100 ; index++)
{
sum +=index;
}
try
{
Thread.sleep(2000);
}
catch(InterruptedException ex)
{
}

notify();
}
}
}

------------------------------------------------------------------------

output:


Reader-1 is waiting ....
Reader-2 is waiting ....
Reader-3 is waiting ....
Reader-2 got notified ..
Reader-2 - total : 4950
Reader-1 got notified ..
Reader-1 - total : 4950
Reader-3 got notified ..
Reader-3 - total : 4950

----------------------------

[jessie143143]

notify causes only one thread to wake up while notify all causes all threads that are in waiting state to wake up