Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21338 > unrolled thread

Threads, waiting for last one to finish

Back to article view | Back to comp.lang.java.programmer

Contents

  Threads, waiting for last one to finish Roedy Green <see_website@mindprod.com.invalid> - 2013-01-11 13:56 -0800
    Re: Threads, waiting for last one to finish markspace <markspace@nospam.nospam> - 2013-01-11 14:05 -0800
      Re: Threads, waiting for last one to finish Roedy Green <see_website@mindprod.com.invalid> - 2013-01-11 14:14 -0800
        Re: Threads, waiting for last one to finish markspace <markspace@nospam.nospam> - 2013-01-11 15:11 -0800
          Re: Threads, waiting for last one to finish Arne Vajhøj <arne@vajhoej.dk> - 2013-01-11 20:02 -0500
          Re: Threads, waiting for last one to finish Roedy Green <see_website@mindprod.com.invalid> - 2013-01-12 01:51 -0800
          Re: Threads, waiting for last one to finish Roedy Green <see_website@mindprod.com.invalid> - 2013-01-12 02:20 -0800
            Re: Threads, waiting for last one to finish Arne Vajhøj <arne@vajhoej.dk> - 2013-01-12 09:08 -0500
          Re: Threads, waiting for last one to finish Roedy Green <see_website@mindprod.com.invalid> - 2013-01-12 10:36 -0800
            Re: Threads, waiting for last one to finish Arne Vajhøj <arne@vajhoej.dk> - 2013-01-12 16:17 -0500
      Re: Threads, waiting for last one to finish Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-12 23:39 -0800
        Re: Threads, waiting for last one to finish Arne Vajhøj <arne@vajhoej.dk> - 2013-01-13 22:35 -0500
          Re: Threads, waiting for last one to finish Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-01-14 09:12 -0800
          Re: Threads, waiting for last one to finish Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-14 22:29 -0800
            Re: Threads, waiting for last one to finish markspace <markspace@nospam.nospam> - 2013-01-15 08:19 -0800
              Re: Threads, waiting for last one to finish Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-16 01:28 -0800
                Re: Threads, waiting for last one to finish Robert Klemme <shortcutter@googlemail.com> - 2013-01-20 15:21 +0100
              Re: Threads, waiting for last one to finish Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-18 21:58 -0800
        Re: Threads, waiting for last one to finish Robert Klemme <shortcutter@googlemail.com> - 2013-01-26 17:20 +0100
    Re: Threads, waiting for last one to finish Knute Johnson <nospam@knutejohnson.com> - 2013-01-11 21:19 -0800
      Re: Threads, waiting for last one to finish Robert Klemme <shortcutter@googlemail.com> - 2013-01-13 19:38 +0100
        Re: Threads, waiting for last one to finish Knute Johnson <nospam@knutejohnson.com> - 2013-01-14 08:58 -0800
        Re: Threads, waiting for last one to finish Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-15 05:05 -0400
    Re: Threads, waiting for last one to finish Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-12 08:42 -0400
      Re: Threads, waiting for last one to finish Roedy Green <see_website@mindprod.com.invalid> - 2013-01-12 23:56 -0800
        Re: Threads, waiting for last one to finish Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-13 10:53 -0400
          Re: Threads, waiting for last one to finish Roedy Green <see_website@mindprod.com.invalid> - 2013-01-13 19:18 -0800
            Re: Threads, waiting for last one to finish Arne Vajhøj <arne@vajhoej.dk> - 2013-01-13 22:26 -0500
              Re: Threads, waiting for last one to finish Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-14 05:51 -0400
                Re: Threads, waiting for last one to finish Arne Vajhøj <arne@vajhoej.dk> - 2013-01-14 19:02 -0500
          Re: Threads, waiting for last one to finish Roedy Green <see_website@mindprod.com.invalid> - 2013-01-13 19:43 -0800
    Re: Threads, waiting for last one to finish Sebastian <news@seyweiler.dyndns.org> - 2013-01-13 15:19 +0100

Page 2 of 2 — ← Prev page 1 [2]

#21381

On 12.01.2013 06:19, Knute Johnson wrote:
> On 1/11/2013 1:56 PM, Roedy Green wrote:
>> I have 25 threads that start at once. I need to wait until the last
>> one completes. Is there a better way to handle that than using a
>> ThreadPoolExecutor which seems overkill.
>>
>
> You can always join() them.

I am surprised that this got just one mention so far.  In absence of 
Executor (which has some issues, as has been mentioned) this is the most 
straightforward way to do it.

// untested and from memory
final Thread[] threads = new Thread[15];

for ( int i = 0; i < threads.length; ++i ) {
   final Thread th = new Thread(...);
   th.start();
   threads[i] = th;
}

for ( final Thread th : threads ) {
   th.join();
}

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#21399

On 1/13/2013 10:38 AM, Robert Klemme wrote:
> On 12.01.2013 06:19, Knute Johnson wrote:
>> On 1/11/2013 1:56 PM, Roedy Green wrote:
>>> I have 25 threads that start at once. I need to wait until the last
>>> one completes. Is there a better way to handle that than using a
>>> ThreadPoolExecutor which seems overkill.
>>>
>>
>> You can always join() them.
>
> I am surprised that this got just one mention so far.

Me too :-).

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#21410

On 01/13/2013 02:38 PM, Robert Klemme wrote:
> On 12.01.2013 06:19, Knute Johnson wrote:
>> On 1/11/2013 1:56 PM, Roedy Green wrote:
>>> I have 25 threads that start at once. I need to wait until the last
>>> one completes. Is there a better way to handle that than using a
>>> ThreadPoolExecutor which seems overkill.
>>>
>>
>> You can always join() them.
>
> I am surprised that this got just one mention so far.  In absence of
> Executor (which has some issues, as has been mentioned) this is the most
> straightforward way to do it.
>
> // untested and from memory
> final Thread[] threads = new Thread[15];
>
> for ( int i = 0; i < threads.length; ++i ) {
>    final Thread th = new Thread(...);
>    th.start();
>    threads[i] = th;
> }
>
> for ( final Thread th : threads ) {
>    th.join();
> }
>
> Kind regards
>
>      robert
>
You're both right, of course. One of the hazards - speaking for myself - 
of seizing on java.util.concurrent and reading JCIP through several 
times is that one may tend to forget the original Java concurrency 
constructs.

I think join() satisfies Roedy's problem statement the best; in any case 
the latches and barriers have different endgame behaviour.

AHS

[toc] | [prev] | [next] | [standalone]

#21351

On 01/11/2013 05:56 PM, Roedy Green wrote:
> I have 25 threads that start at once. I need to wait until the last
> one completes. Is there a better way to handle that than using a
> ThreadPoolExecutor which seems overkill.
>
Any reason why you couldn't use CyclicBarrier?

AHS

[toc] | [prev] | [next] | [standalone]

#21373

On Sat, 12 Jan 2013 08:42:45 -0400, Arved Sandstrom
<asandstrom2@eastlink.ca> wrote, quoted or indirectly quoted someone
who said :

>Any reason why you couldn't use CyclicBarrier?

There are a few things that puzzle.  What goes in the unshown
waitUntilDone? just an await?  I suppose the mother thread too counts
as one of the "parties".

Why does CyclicBarrier have a Runnable? Would it not be simpler to
have the mother thread invoke a Runnable after the await? or just
execute the cleanup code on the same thread?

With CyclicBarrier, you must know the precise number of threads ahead
of time that will wait. In my case I have an upper bound.  Sometimes
there is nothing to do for a given thread, and I don't even start it.
To use CyclicBarrier I would need a pre-sweep to get the precise
count.

In my case, one of the threads, the one that probes amazon.cn takes
quite a bit longer than the others.  The way it is now, all the
threads but one shut down early and let the last thread have all the
resources.  With CyclicBarrier they would all be hanging around to the
last minute.

Thank you for bringing this option up. I tend use to overuse the first
tool I encounter out of learning curve fear.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#21379

On 01/13/2013 03:56 AM, Roedy Green wrote:
> On Sat, 12 Jan 2013 08:42:45 -0400, Arved Sandstrom
> <asandstrom2@eastlink.ca> wrote, quoted or indirectly quoted someone
> who said :
>
>> Any reason why you couldn't use CyclicBarrier?
>
> There are a few things that puzzle.  What goes in the unshown
> waitUntilDone? just an await?  I suppose the mother thread too counts
> as one of the "parties".
>
> Why does CyclicBarrier have a Runnable? Would it not be simpler to
> have the mother thread invoke a Runnable after the await? or just
> execute the cleanup code on the same thread?
>
> With CyclicBarrier, you must know the precise number of threads ahead
> of time that will wait. In my case I have an upper bound.  Sometimes
> there is nothing to do for a given thread, and I don't even start it.
> To use CyclicBarrier I would need a pre-sweep to get the precise
> count.
>
> In my case, one of the threads, the one that probes amazon.cn takes
> quite a bit longer than the others.  The way it is now, all the
> threads but one shut down early and let the last thread have all the
> resources.  With CyclicBarrier they would all be hanging around to the
> last minute.
>
> Thank you for bringing this option up. I tend use to overuse the first
> tool I encounter out of learning curve fear.
>
It's this option and also its close cousin the CountdownLatch - useful 
synchronization constructs to be aware of.

I'll refer you to JCIP for a detailed exposition of the details between 
CountdownLatch and CyclicBarrier - the key difference is that the latch 
is waiting for an event (the latch count becoming 0 through invocations 
of countDown()) while the barrier waits on other threads (these threads 
arriving at the barrier when they call await()).

In either case, yes, you need to supply the number of threads involved. 
That's to be expected. I have difficulty seeing how you wouldn't be able 
to figure out how many threads you propose to start.

As for the Runnable for CyclicBarrier, you want to read the Javadoc 
carefully. The barrier is going to run that *after* all threads arrive, 
but *before* they are released - you're welcome to try and implement 
that yourself.

As for threads taking different times, and "hanging around", I don't see 
the problem. If each individual thread does resource cleanup - like 
connections - before calling await(), what is the issue with a thread 
doing basically nothing?

AHS

[toc] | [prev] | [next] | [standalone]

#21388

On Sun, 13 Jan 2013 10:53:58 -0400, Arved Sandstrom
<asandstrom2@eastlink.ca> wrote, quoted or indirectly quoted someone
who said :

>As for threads taking different times, and "hanging around", I don't see 
>the problem. If each individual thread does resource cleanup - like 
>connections - before calling await(), what is the issue with a thread 
>doing basically nothing?

does not a thread have 1 MB + overhead just for existing?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#21389

On 1/13/2013 10:18 PM, Roedy Green wrote:
> On Sun, 13 Jan 2013 10:53:58 -0400, Arved Sandstrom
> <asandstrom2@eastlink.ca> wrote, quoted or indirectly quoted someone
> who said :
>> As for threads taking different times, and "hanging around", I don't see
>> the problem. If each individual thread does resource cleanup - like
>> connections - before calling await(), what is the issue with a thread
>> doing basically nothing?
>
> does not a thread have 1 MB + overhead just for existing?

Yes, no, it depends.

It is implementation dependent so it can and do differ between
different vendors and platforms.

Some may provide an option for changing the default.

I have once read that SUN/Oracle Java on Windows and Linux uses
320 KB and 1024KB as default on 32 and 64 bit respectively.

SUN/Oracle Java do provide the -Xss option to change the
default.

Arne

[toc] | [prev] | [next] | [standalone]

#21396

On 01/13/2013 11:26 PM, Arne Vajhøj wrote:
> On 1/13/2013 10:18 PM, Roedy Green wrote:
>> On Sun, 13 Jan 2013 10:53:58 -0400, Arved Sandstrom
>> <asandstrom2@eastlink.ca> wrote, quoted or indirectly quoted someone
>> who said :
>>> As for threads taking different times, and "hanging around", I don't see
>>> the problem. If each individual thread does resource cleanup - like
>>> connections - before calling await(), what is the issue with a thread
>>> doing basically nothing?
>>
>> does not a thread have 1 MB + overhead just for existing?
>
> Yes, no, it depends.
>
> It is implementation dependent so it can and do differ between
> different vendors and platforms.
>
> Some may provide an option for changing the default.
>
> I have once read that SUN/Oracle Java on Windows and Linux uses
> 320 KB and 1024KB as default on 32 and 64 bit respectively.
>
> SUN/Oracle Java do provide the -Xss option to change the
> default.
>
> Arne
>
I use the -Xss on occasion for some apps, sometimes it's part of their 
tuning docs. Usually I don't worry about thread stack size, not if I've 
got a relatively small number (25 certainly being small) of threads.

Not when I need GB of memory for heap, and hundreds of megs for perm gen.

My approach here is my usual approach - go for a simple design, and if a 
quick gut-check of performance implications raises no red flags then go 
with that for implementation.

AHS

[toc] | [prev] | [next] | [standalone]

#21402

On 1/14/2013 4:51 AM, Arved Sandstrom wrote:
> On 01/13/2013 11:26 PM, Arne Vajhøj wrote:
>> On 1/13/2013 10:18 PM, Roedy Green wrote:
>>> On Sun, 13 Jan 2013 10:53:58 -0400, Arved Sandstrom
>>> <asandstrom2@eastlink.ca> wrote, quoted or indirectly quoted someone
>>> who said :
>>>> As for threads taking different times, and "hanging around", I don't
>>>> see
>>>> the problem. If each individual thread does resource cleanup - like
>>>> connections - before calling await(), what is the issue with a thread
>>>> doing basically nothing?
>>>
>>> does not a thread have 1 MB + overhead just for existing?
>>
>> Yes, no, it depends.
>>
>> It is implementation dependent so it can and do differ between
>> different vendors and platforms.
>>
>> Some may provide an option for changing the default.
>>
>> I have once read that SUN/Oracle Java on Windows and Linux uses
>> 320 KB and 1024KB as default on 32 and 64 bit respectively.
>>
>> SUN/Oracle Java do provide the -Xss option to change the
>> default.
>>
> I use the -Xss on occasion for some apps, sometimes it's part of their
> tuning docs. Usually I don't worry about thread stack size, not if I've
> got a relatively small number (25 certainly being small) of threads.
>
> Not when I need GB of memory for heap, and hundreds of megs for perm gen.
>
> My approach here is my usual approach - go for a simple design, and if a
> quick gut-check of performance implications raises no red flags then go
> with that for implementation.

I think I have only used it once and that was a demo to prove that
Tomcat could handle 1000 executing but waiting requests in parallel.

But Roedy seemed concerned and the option is there.

Arne

[toc] | [prev] | [next] | [standalone]

#21391

On Sun, 13 Jan 2013 10:53:58 -0400, Arved Sandstrom
<asandstrom2@eastlink.ca> wrote, quoted or indirectly quoted someone
who said :

>I have difficulty seeing how you wouldn't be able 
>to figure out how many threads you propose to start.

I easily do it, it is just that in my case it takes an extra pass.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#21378

Am 11.01.2013 22:56, schrieb Roedy Green:
> I have 25 threads that start at once. I need to wait until the last
> one completes. Is there a better way to handle that than using a
> ThreadPoolExecutor which seems overkill.

You could use a Phaser, like so:

   final Phaser phaser = new Phaser(1);
   for(int i=0; i < taskCount; i++) {
     phaser.register();
     executor.execute(new Runnable() {
       public void run() {
         try {
              // do sth
           );
         } catch (InterruptedException e) {
              Thread.currentThread().interrupt();
         }
         phaser.arrive();
       }
     });
   }
   phaser.arriveAndAwaitAdvance();


-- Sebastian

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web