headers
David Holmes | 1 Apr 2005 01:47
Picon

RE: Tree{Map,Set}

I'm not at all clear on what you have done. What is a LinkedQueue? How does
it perform synchronization?

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces <at> cs.oswego.edu
> [mailto:concurrency-interest-bounces <at> cs.oswego.edu]On Behalf Of
> Pollachi, Saikumar
> Sent: Friday, 1 April 2005 4:58 AM
> To: concurrency-interest <at> altair.cs.oswego.edu
> Subject: RE: [concurrency-interest] Tree{Map,Set}
>
>
>
> Hi!
>
> I am a silent member of the group. I enjoy reading the mails from this
> group. Can somebody tell me if there is any possibility of deadlocks in
> this code. I extended LinkedQueue to create  a PersistentQueue. It works
> fine most of the time. Some time I suspect there is a dead lock.
>
>
> public class PersistentQueue
>     extends LinkedQueue
> {
>     private void restoreQueue()
>     {
> 	...
>     }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pollachi, Saikumar | 1 Apr 2005 16:26
Favicon

RE: Tree{Map,Set}

Hi!

I missed the import statements in the code snippet. I am using LinkedQueue of Doug Lea's concurrent library.

The class is  packaged in EDU.oswego.cs.dl.util.concurrent.

In my persist() method I am synchronizing on 'head_' (a LinkedNode) instance variable in LinkedQueue
class. Will this cause any dead locks when put(Object) and get() methods are being called in different threads?

Thanks...

-----Original Message-----
From: David Holmes [mailto:dholmes <at> dltech.com.au]
Sent: Thursday, March 31, 2005 6:48 PM
To: Pollachi, Saikumar; concurrency-interest <at> altair.cs.oswego.edu
Subject: RE: [concurrency-interest] Tree{Map,Set}

I'm not at all clear on what you have done. What is a LinkedQueue? How does
it perform synchronization?

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces <at> cs.oswego.edu
> [mailto:concurrency-interest-bounces <at> cs.oswego.edu]On Behalf Of
> Pollachi, Saikumar
> Sent: Friday, 1 April 2005 4:58 AM
> To: concurrency-interest <at> altair.cs.oswego.edu
> Subject: RE: [concurrency-interest] Tree{Map,Set}
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
hernan.otero | 2 Apr 2005 00:55
Picon

ThreadPoolExecutor customization proposal/question

I would like to use a ThreadPoolExecutor but would like to impose a couple
of restrictions on how tasks (Runnables) are executed.  Basically, I would
like to have each task execute on a specific "context" (each context having
a unique String-typed id).  I would like my executor to guarantee
serialization of the tasks at the context level (e.g. no two tasks for the
same context should ever be executed in parallel).  So if two tasks are
queued in order (e.g. by the same thread), then their execution should also
be guaranteed to execute in the same order.

If I were to implement this as a customization to the existing
ThreadPoolExecutor, I would probably think of going the following route:

interface RunnableContext
{

}

interface ContextRunnable extends Runnable
{

RunnableContext getContext();

}

public class ThreadPoolContextExecutor extends ThreadPoolExecutor {

Runnable getTask() {
  // the code that looks for the next task would need to skip tasks for
"currently busy" contexts
}
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joe Bowbeer | 2 Apr 2005 11:23

Re: ThreadPoolExecutor customizationproposal/question

Hernan,

How many contexts are there?  Are they known before hand?

I suggest you look at SerialExecutor in the Executor javadoc (if you haven't 
already).  The idea being that you can use an instance of SerialExecutor per 
context, all of them sharing a single ThreadPoolExecutor.

If SerialExecutor isn't a good fit, I suggest you try a different composite 
executor design, or create a specialized queue, leaving ThreadPoolExecutor 
to do its thread pool thing unencumbered.

----- Original Message ----- 
From: <hernan.otero <at> jpmchase.com>
To: <concurrency-interest <at> altair.cs.oswego.edu>
Sent: Friday, April 01, 2005 2:55 PM
Subject: [concurrency-interest] ThreadPoolExecutor 
customizationproposal/question

I would like to use a ThreadPoolExecutor but would like to impose a couple
of restrictions on how tasks (Runnables) are executed.  Basically, I would
like to have each task execute on a specific "context" (each context having
a unique String-typed id).  I would like my executor to guarantee
serialization of the tasks at the context level (e.g. no two tasks for the
same context should ever be executed in parallel).  So if two tasks are
queued in order (e.g. by the same thread), then their execution should also
be guaranteed to execute in the same order.

If I were to implement this as a customization to the existing
ThreadPoolExecutor, I would probably think of going the following route:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hernan Otero | 2 Apr 2005 19:08
Picon

Re: ThreadPoolExecutor customizationproposal/question

The number of contexts is unknown before hand (and could significantly 
go up/down at runtime).  A rough number would be 5,000.

Will look into your proposed alternatives.

Thanks,

Hernan

On Apr 2, 2005, at 4:23 AM, Joe Bowbeer wrote:

> Hernan,
>
> How many contexts are there?  Are they known before hand?
>
> I suggest you look at SerialExecutor in the Executor javadoc (if you 
> haven't
> already).  The idea being that you can use an instance of 
> SerialExecutor per
> context, all of them sharing a single ThreadPoolExecutor.
>
> If SerialExecutor isn't a good fit, I suggest you try a different 
> composite
> executor design, or create a specialized queue, leaving 
> ThreadPoolExecutor
> to do its thread pool thing unencumbered.
>
>
> ----- Original Message -----
> From: <hernan.otero <at> jpmchase.com>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joe Bowbeer | 3 Apr 2005 00:07

Re: ThreadPoolExecutorcustomizationproposal/question

Hernan Otero writes:

> The number of contexts is unknown before hand
> (and could significantly go up/down at runtime).
> A rough number would be 5,000.

One approach would be to add a map of execution contexts to SerialExecutor. 
Note that unused contexts can be removed in the scheduleNext method.

A crude implementation along these lines follows.

ContextExecutor maps context keys to execution contexts, and serializes the 
execution of tasks for each context.  An execution context in this case is 
the active task and a queue of waiting tasks.  New contexts are created on 
demand and removed when they are no longer used.

import java.util.HashMap;
import java.util.Map;
import java.util.Queue;
import java.util.concurrent.Executor;
import java.util.concurrent.LinkedBlockingQueue;

class ContextExecutor implements Executor {

    static class Context {
        final Queue<Runnable> tasks =
            new LinkedBlockingQueue<Runnable>();
        final String key;
        Runnable active;
        Context(String key) {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joe Bowbeer | 3 Apr 2005 02:19

Re: ThreadPoolExecutorcustomizationproposal/question

By the way,

I want to point out that there's no need for this code to use a concurrent 
map or a concurrent queue implementation because this executor's state is 
synchronized at execute and scheduleNext.

Any Queue will do, such as a LinkedList.  I'd recommend switching to 
LinkedList to reduce the overhead per context.

  final Queue<Runnable> tasks = new LinkedList<Runnable>();

----- Original Message ----- 
From: "Joe Bowbeer" <jozart <at> blarg.net>
To: <concurrency-interest <at> altair.cs.oswego.edu>; "Hernan Otero" 
<hernan.otero <at> mac.com>
Sent: Saturday, April 02, 2005 2:07 PM
Subject: Re: 
[concurrency-interest]ThreadPoolExecutorcustomizationproposal/question

Hernan Otero writes:

> The number of contexts is unknown before hand
> (and could significantly go up/down at runtime).
> A rough number would be 5,000.

One approach would be to add a map of execution contexts to SerialExecutor.
Note that unused contexts can be removed in the scheduleNext method.

A crude implementation along these lines follows.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Minnie Haridasa | 4 Apr 2005 06:51
Picon

Cancelling Tasks returning immediately..

Hello,

 

We have unique situation where I thought I may seek you help for some useful hints.

My thread pool has an unbounded queue associated to it. However, while a task is waiting on the queue to be

Processed, it cannot wait indefinitely, after a certain period of time, it needs to cancel out and return a different result.

 

Is it possible to achieve this using the concurrent utilities of JDK1.5.

 

My queue has to be unbounded, and the task (callable) that gets put on the queue needs to be time bound. How can I make the cancelled task return immediately as opposed to the result that can only be retrieved using method get when the computation has completed or the task gets its turn to be executed by the pool.

 

Appreciate your help.

Thanks

MH

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Permalink | Reply | 4 comments |
headers
Joe Bowbeer | 4 Apr 2005 07:45

Re: Cancelling Tasks returning immediately..

Here's a simple approach:

When you submit your FutureTask to the executor service, also schedule a 
TimerTask to cancel that task.

If your FutureTask needs to act at the moment it is cancelled, override the 
"done" method and perform the desired action if isCancelled returns true.

----- Original Message ----- 
From: "Minnie Haridasa" <minnieh <at> corp.earthlink.net>
To: <concurrency-interest <at> altair.cs.oswego.edu>
Sent: Sunday, April 03, 2005 9:51 PM
Subject: [concurrency-interest] Cancelling Tasks returning immediately..

Hello,

We have unique situation where I thought I may seek you help for some useful
hints.

My thread pool has an unbounded queue associated to it. However, while a
task is waiting on the queue to be

Processed, it cannot wait indefinitely, after a certain period of time, it
needs to cancel out and return a different result.

Is it possible to achieve this using the concurrent utilities of JDK1.5.

My queue has to be unbounded, and the task (callable) that gets put on the
queue needs to be time bound. How can I make the cancelled task return
immediately as opposed to the result that can only be retrieved using method
get when the computation has completed or the task gets its turn to be
executed by the pool.

Appreciate your help.

Thanks

MH
Permalink | Reply | 3 comments |
headers
Minnie Haridasa | 5 Apr 2005 02:12
Picon

RE: Pausing the idle threads in a pool for small time.

Thank you Joe!! However I had another question to the group.

Is it possible to pause/resume the idle threads in the pool? I am trying to
implement request throttling.  In the process of doing so, I would like to
pause all the idle threads in the pool once the request counter reaches its
maximum to up until the request rate counter is reset. The request rate
counter is gets reset every 1 second and is supposed to allow only 4
requests to pass through. 

Regards,
Minnie

-----Original Message-----
From: Joe Bowbeer [mailto:jozart <at> blarg.net] 
Sent: Sunday, April 03, 2005 10:46 PM
To: Minnie Haridasa; concurrency-interest <at> altair.cs.oswego.edu
Subject: Re: [concurrency-interest] Cancelling Tasks returning immediately..

Here's a simple approach:

When you submit your FutureTask to the executor service, also schedule a 
TimerTask to cancel that task.

If your FutureTask needs to act at the moment it is cancelled, override the 
"done" method and perform the desired action if isCancelled returns true.

----- Original Message ----- 
From: "Minnie Haridasa" <minnieh <at> corp.earthlink.net>
To: <concurrency-interest <at> altair.cs.oswego.edu>
Sent: Sunday, April 03, 2005 9:51 PM
Subject: [concurrency-interest] Cancelling Tasks returning immediately..

Hello,

We have unique situation where I thought I may seek you help for some useful
hints.

My thread pool has an unbounded queue associated to it. However, while a
task is waiting on the queue to be

Processed, it cannot wait indefinitely, after a certain period of time, it
needs to cancel out and return a different result.

Is it possible to achieve this using the concurrent utilities of JDK1.5.

My queue has to be unbounded, and the task (callable) that gets put on the
queue needs to be time bound. How can I make the cancelled task return
immediately as opposed to the result that can only be retrieved using method
get when the computation has completed or the task gets its turn to be
executed by the pool.

Appreciate your help.

Thanks

MH
Permalink | Reply | 0 comments |

Gmane