listner or observer

[gk]

i have multithread. each thread takes different amount of time to
complete their tasks. i want to collect all the results immediately as
soon as individuals finishes.

i dont want to use join method of thred. i want to make a
listner/observer which would collect theresults as soon as threads
finisehes . and at last give me back the total result.


How to do this thing ?
where do i get the coding example for this ?

 

[klynn47]

One thing you might try is to have a single method which is
synchronized which adds results to some collection like a TreeSet.

 

[gk]

hi, please show me an example. do you know any such website link how
to solve this problem ?

 

[Roedy Green]

hi, please show me an example. do you know any such website link how
to solve this problem ?

Each thread has access to the collection. If the collection is type
safe it just does an add with an object representing the results. If
the collection is not type safe it can wrap the call to add in a block
synchronised on the collection itself.


Now you are left with the problem of detecting last thread to finish.
There are classes in java.util.concurrent for that sort of thing.
see http://mindprod.com/jgloss/queue.html

Otherwise you need synchronised countdown int that each task
decrements just before it quits. If it hits 0 it calls some done
method.

 

[Thomas G. Marshall]

Roedy Green coughed up:

Each thread has access to the collection. If the collection is type
safe

thread safe

it just does an add with an object representing the results. If
the collection is not type safe

thread safe

 

[Roedy Green]

thread safe

I have am suffering from the cough of my life. It has gone on a month
now and shakes me to the bones. The various remedies partner offers
make me even stupider than usual. Sorry about that.

 

[Thomas G. Marshall]

Roedy Green coughed up:

On Tue, 04 Oct 2005 22:17:06 GMT, "Thomas G. Marshall"


I have am suffering from the cough of my life. It has gone on a month
now and shakes me to the bones. The various remedies partner offers
make me even stupider than usual. Sorry about that.

Not to turn this into alt.gonnadie, but did you have a dr. check you for
bacterial/viral pneumonia? Various forms of that thing are flying around,
and I know a couple people who got it. Not something to @#$% with.

 

[gk]

i have questions.
you told to make a class which will have a collection to store the
results.
each thread will go to collection and puts their results into that .
but WHEN a thread will be finished , How it will be determined ? i dont
want to use join method , because it make the things as a serial
execution .

thanks for the encyclopedia link. thats a very good encyclopedia.

 

[jonck]

but WHEN a thread will be finished , How it will be determined ? i dont

want to use join method , because it make the things as a serial
execution .

That's the whole point isn't it, you don't know when it will be
finished, hence the listener. So what exactly is your question? How to
implement a listener? Should this indeed be the case, check out the
following article:
http://www.javaworld.com/javaworld/javaqa/2000-08/01-qa-0804-events.html

 

[Thomas G. Marshall]

gk coughed up:

i have questions.
you told to make a class which will have a collection to store the
results.
each thread will go to collection and puts their results into that .
but WHEN a thread will be finished , How it will be determined ? i
dont want to use join method , because it make the things as a serial
execution .

This is to the side of your specific issue, but I think that you are perhaps
confused a little about the common usage of join().

For example, commonly, the MO might be as follows:

1. launch a bazillion threads, using say an array of Runnables to store
them.
2. (let the threads to their thing)
3. for (int i=0; i<bazillion; i++) runnable.join();

This will loop through each of the threads and essentially wait for all of
them to finish. If any one of them is alreay dead, the join() just returns.

The threads ARE NOT being executed serially. They are just being waited for
completion that way.

You can always set up a call back (using a listener interface) as the very
last thing for a thread to execute. Or just be more direct and have the
last thing a thread call be Someplace.done(), so long as done() is
synchronized so that two or more threads don't trip over each other
executing the contents of done().

 

[gk]

2. (let the threads to their thing)

3. for (int i=0; i<bazillion; i++) runnable.join();

I ALWAYS DO THIS WAY. and i wanted to avoid this.

You can always set up a call back (using a listener interface) as the very
last thing for a thread to execute. Or just be more direct and have the
last thing a thread call be Someplace.done(), so long as done() is
synchronized so that two or more threads don't trip over each other
executing the contents of done().

NOTHING UNDERSTOOD .

in java 1.5 there is a future class which does the AUTO RETURN when a
thread is finished.

However, i dont want to upgrade to 1.5 .

do you mean , in java 1.5 future class use this join() method
INTERNALLY ? of course, i dont know, i have not seen the source code of
future class.

 

[gk]

YES, exactly i was looking for this.

but that tutorial is for SWING application and not complete
implementaion .
i want to use that for threads .

 

[dnasmars]

YES, exactly i was looking for this.

but that tutorial is for SWING application and not complete
implementaion .
i want to use that for threads .

have a look a this
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html?
migth help
IMHO you'll have to add a synchronized to the add and remove methods
hope this helps

 

[gk]

Excellent excellent. i was looking for this . great man

 

[Thomas G. Marshall]

gk coughed up:

2. (let the threads to their thing)
3. for (int i=0; i<bazillion; i++) runnable.join();

I ALWAYS DO THIS WAY. and i wanted to avoid this.

Don't shout.

What you said was this:

You: (gk)
i dont want to use join method , because it
make the things as a serial execution

This is entirely unclear! You certainly don't get the threads themselves as
serially executed. And the join() is merely to wait for them all to finish.

....[rip]...

 

[gk]

sorry . you are right. i take back my words . i was confused about
should i use join() or should not .

it is called use of observer or listner in a multithreading problem
makes the code more robust,sophisticated. so, i wanted to know whether
ther is any other way out .
my statement about "serial execution" is baseless.

Thank you for the correction

 

[Thomas G. Marshall]

gk coughed up:

sorry . you are right. i take back my words . i was confused about
should i use join() or should not .

it is called use of observer or listner in a multithreading problem
makes the code more robust,sophisticated. so, i wanted to know
whether ther is any other way out .
my statement about "serial execution" is baseless.

Thank you for the correction

No harm done. The good news in all this is that you've discovered just how
clear and easy to implement listeners and observers are.

--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.