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

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

thread pool with CachedThreadPool

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

Contents

  thread pool with CachedThreadPool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-04-15 10:47 +0200
    Re: thread pool with CachedThreadPool Joerg Meier <joergmmeier@arcor.de> - 2014-04-15 12:02 +0200
      Re: thread pool with CachedThreadPool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-04-15 12:40 +0200
        Re: thread pool with CachedThreadPool Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-04-15 15:05 -0700
          Re: thread pool with CachedThreadPool Robert Klemme <shortcutter@googlemail.com> - 2014-04-16 08:43 +0200
            Re: thread pool with CachedThreadPool Josip Almasi <joe@vrspace.org> - 2014-04-16 12:42 +0200
              Re: thread pool with CachedThreadPool Robert Klemme <shortcutter@googlemail.com> - 2014-04-16 17:55 +0200
                Re: thread pool with CachedThreadPool Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-04-16 22:11 -0700
                  Re: thread pool with CachedThreadPool Josip Almasi <joe@vrspace.org> - 2014-04-17 12:12 +0200

#28088 — thread pool with CachedThreadPool

Hello,

I try to use the Executors.newCachedThreadPool to create a pool with runnables:

class myPool
{

private boolean running = false;
ExecutorService pool = Executors.newCachedThreadPool();

public void start()
{
    running = true;
    for(int i=0; i < poolsize; i++)
	pool.submit( new myWorker(this) );
}

public void stop()
{
        running = false;
        pool.shutdown();
        try {
            m_pool.awaitTermination(5, TimeUnit.SECONDS);
        } catch (InterruptedException ex) {}
}

public boolean isRunning()
{
    return running;
}

}

class myWortker implements Runnable
{
     private myPool master = null;

     public myWorker( myPool pool ) { master = pool; }

     public void run()
     {
            while(master.isRunning)
            {
                  do a lot of work
            }
}

I have removed any synchronized calls to show the basic structure only. 
If I run
myPool pool = new myPool();
pool.start()
pool.stop();

everything works fine, all workers are started and all workers shut 
down. If I call after the stop() the start()
method again I get an exception 
"java.util.concurrent.RejectedExecutionException".

IMHO start() should create all workers and stop() should shutdown the 
pool and a new start call should create the pool with workers again. 
Did I missing anything? I think I don't understand the pool logic in a 
correct manner. Can anybody explain me my mistake?

Thanks a lot

Phil

[toc] | [next] | [standalone]

#28089

On Tue, 15 Apr 2014 10:47:02 +0200, Philipp Kraus wrote:

> If I run
> myPool pool = new myPool();
> pool.start()
> pool.stop();

> everything works fine, all workers are started and all workers shut 
> down. If I call after the stop() the start()
> method again I get an exception 
> "java.util.concurrent.RejectedExecutionException".

That is because you have shut the pool down. Once a pool is shut down, no
more tasks can be submitted. And it would not make any sense to submit new
tasks to a pool that has been ordered not to execute new tasks. There is,
as far as I know, no way to revert the state of a pool back to running once
it enters shutdown mode.

If you want a pauseable pool, you might want to look at the API
documentation for ThreadPoolExecutor, which has a simple example for
extending the class:

<http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html>

Search for "For example, here is a subclass that adds a simple pause/resume
feature:".

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#28090

On 2014-04-15 10:02:56 +0000, Joerg Meier said:

> On Tue, 15 Apr 2014 10:47:02 +0200, Philipp Kraus wrote:
> 
> If you want a pauseable pool, you might want to look at the API
> documentation for ThreadPoolExecutor, which has a simple example for
> extending the class:
> 
> <http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html> 
> 
> 
> Search for "For example, here is a subclass that adds a simple pause/resume
> feature:".

Thanks imho the "shutdown" should be the "pause" option. I think it was 
a missunderstanding of the shutdown call

Phil

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

#28094

On 4/15/14 3:40 AM, Philipp Kraus wrote:
> On 2014-04-15 10:02:56 +0000, Joerg Meier said:
>
>> On Tue, 15 Apr 2014 10:47:02 +0200, Philipp Kraus wrote:
>>
>> If you want a pauseable pool, you might want to look at the API
>> documentation for ThreadPoolExecutor, which has a simple example for
>> extending the class:
>>
>> <http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html>
>>
>>
>> Search for "For example, here is a subclass that adds a simple
>> pause/resume
>> feature:".
>
> Thanks imho the "shutdown" should be the "pause" option. I think it was
> a missunderstanding of the shutdown call

Why pause? All your tasks have completed, so all the "workers" that may 
still be running are "paused" automatically, awaiting a signal to start 
up again.

"Threads" with nothing to do take up very little CPU.  They may take up 
memory or other resources, but they can be made to do nothing until 
called for.

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

#28098

On 16.04.2014 00:05, Daniel Pitts wrote:

> "Threads" with nothing to do take up very little CPU.  They may take up
> memory or other resources, but they can be made to do nothing until
> called for.

What do they take CPU for other than that negligible amount of time the 
kernel takes for administering them?  I'd say for all practical purposes 
you can assume a blocked thread to take up zero %CPU.  Or am I missing 
something?

Cheers

	robert

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

#28100

On 04/16/2014 08:43 AM, Robert Klemme wrote:
> On 16.04.2014 00:05, Daniel Pitts wrote:
>
>> "Threads" with nothing to do take up very little CPU.  They may take up
>> memory or other resources, but they can be made to do nothing until
>> called for.
>
> What do they take CPU for other than that negligible amount of time the
> kernel takes for administering them?  I'd say for all practical purposes
> you can assume a blocked thread to take up zero %CPU.  Or am I missing
> something?

Blocked thread itself spends no cpu time.
Running thread may spend some more cpu time though, for lock checks.
Real issue is flushing pipeline to ensure cache coherency among all cpu 
cores.
So, more 'synchronized' statements your single running thread 
encounters, more cpu stalls. It's not really 'taking' cpu time, it's 
wasting it.
I have to admit, intel pipeline is complete mistery to me:)
But that's why have atomics and other non-blocking thread-safe magic.

Regards...

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

#28105

On 16.04.2014 12:42, Josip Almasi wrote:
> On 04/16/2014 08:43 AM, Robert Klemme wrote:
>> On 16.04.2014 00:05, Daniel Pitts wrote:
>>
>>> "Threads" with nothing to do take up very little CPU.  They may take up
>>> memory or other resources, but they can be made to do nothing until
>>> called for.
>>
>> What do they take CPU for other than that negligible amount of time the
>> kernel takes for administering them?  I'd say for all practical purposes
>> you can assume a blocked thread to take up zero %CPU.  Or am I missing
>> something?
>
> Blocked thread itself spends no cpu time.
> Running thread may spend some more cpu time though, for lock checks.
> Real issue is flushing pipeline to ensure cache coherency among all cpu
> cores.
> So, more 'synchronized' statements your single running thread
> encounters, more cpu stalls. It's not really 'taking' cpu time, it's
> wasting it.

I don't think this applies.  We were talking about threads idling in the 
pool.

> I have to admit, intel pipeline is complete mistery to me:)
> But that's why have atomics and other non-blocking thread-safe magic.

The straightforward implementation will block them so there is no CPU 
consumption.  Custom implementations of thread pools may employ spin 
locks but that usually is only done if you expect to always have work 
for all threads.

Cheers

	robert

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

#28115

In article <br7nfqFbmbrU1@mid.individual.net>,
 Robert Klemme <shortcutter@googlemail.com> wrote:

> On 16.04.2014 12:42, Josip Almasi wrote:
> > On 04/16/2014 08:43 AM, Robert Klemme wrote:
> >> On 16.04.2014 00:05, Daniel Pitts wrote:
> >>
> >>> "Threads" with nothing to do take up very little CPU.  They may take up
> >>> memory or other resources, but they can be made to do nothing until
> >>> called for.
> >>
> >> What do they take CPU for other than that negligible amount of time the
> >> kernel takes for administering them?  I'd say for all practical purposes
> >> you can assume a blocked thread to take up zero %CPU.  Or am I missing
> >> something?
> >
> > Blocked thread itself spends no cpu time.
> > Running thread may spend some more cpu time though, for lock checks.
> > Real issue is flushing pipeline to ensure cache coherency among all cpu
> > cores.
> > So, more 'synchronized' statements your single running thread
> > encounters, more cpu stalls. It's not really 'taking' cpu time, it's
> > wasting it.
> 
> I don't think this applies.  We were talking about threads idling in the 
> pool.
> 
> > I have to admit, intel pipeline is complete mistery to me:)
> > But that's why have atomics and other non-blocking thread-safe magic.
> 
> The straightforward implementation will block them so there is no CPU 
> consumption.  Custom implementations of thread pools may employ spin 
> locks but that usually is only done if you expect to always have work 
> for all threads.
> 
> Cheers
> 
> 	robert

Sun's thread pools are garbage because some of the API is not logically 
possible to implement.  I don't recommend starting, stopping, or 
resizing except when absolutely necessary.  Create a large fixed size 
pool and leave it running.


None of the Sun thread pools can garbage collect if left running or if 
shutdown() malfunctions.  No, you can't create a ThreadPoolExecutor with 
a minimum size of zero.  See the next bug...

All Sun executors might not create new threads as needed.  If new 
threads are required for existing threads to finish a task, it will 
eventually deadlock.  A core size of zero may cause tasks to not execute 
until new tasks are submitted.

ThreadPoolExecutor round robins threads so excess threads may never hit 
their timeout as long as even one task is regularly running.

ThreadPoolExecutor prefers to create a new thread rather than wait for 
an existing thread to finish.  Creating a new thread is expensive and it 
prevents other threads from finishing.  As a result, a rapid task 
injections always drive ThreadPoolExecutor to the maximum thread count, 
or OOM.

ScheduledExecutorService has a bug in shutdown() that spins loops until 
all future tasks have completed, no matter how far out that may be.  It 
must not be used.

Interface ScheduledFuture/Delayed can not be implemented safely.  
Delayed.getDelay(TimeUnit) produces an arbitrarily changing value that 
prevents compareTo(Delayed) from being stable.  An unstable compareTo() 
fatally corrupts the task queue.  An unsafe cast to an object producing 
an absolute time is needed (Sun does this).

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

#28117

On 04/17/2014 07:11 AM, Kevin McMurtrie wrote:
> In article <br7nfqFbmbrU1@mid.individual.net>,
>   Robert Klemme <shortcutter@googlemail.com> wrote:
>
>> On 16.04.2014 12:42, Josip Almasi wrote:
>>>
>>> Blocked thread itself spends no cpu time.
>>> Running thread may spend some more cpu time though, for lock checks.
>>> Real issue is flushing pipeline to ensure cache coherency among all cpu
>>> cores.
>>> So, more 'synchronized' statements your single running thread
>>> encounters, more cpu stalls. It's not really 'taking' cpu time, it's
>>> wasting it.
>>
>> I don't think this applies.  We were talking about threads idling in the
>> pool.

[snip]

Probably so.
But, see, it's not just 'small ammount of kernel time', issues go all 
the way to cpu design.

> Sun's thread pools are garbage

[snip]

Dang.
Thanks Kevin, you possibly saved me a lot of time.

Regards...

[toc] | [prev] | [standalone]

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

csiph-web