Nabble - JSR166 Concurrency

Re: out of order execution on uniprocessor

2009-12-10T05:55:31Z

Some time ago I placed a blogpost about this topic:

http://pveentjer.wordpress.com/2008/10/27/jmm-single-processor-can-also-suffer-from-visibility-problems/

On Tue, Dec 8, 2009 at 7:37 PM, Boehm, Hans <hans.boehm@...> wrote:

> If you are writing Java code, it doesn't matter whether you're on a
> uniprocessor. The hardware generally won't visibly reorder memory accesses
> on a uniprocessor, but the compiler still will. And you'd be hard pressed
> to tell the difference.
>
> If you are building a JVM, then it does matter. Since the hardware doesn't
> reorder, you can take some shortcuts.
>
> Both of the excerpts below are correct, but they're targeting a different
> audience.
>
> Hans
>
> P.S. I do think there are a few statements in the cookbook that are in need
> of an update. The ppc and pa-risc situations are more complex than what's
> stated there. (The PA_RISC recipe works for actual hardware, but I think
> the emulator on Itanium follows the rules inthe manual, which allow more
> reordering. For PPC, I think the recipes for sequentially consistent
> operations in
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html also
> apply to Java volatiles and are more accurate.)
>
> ________________________________
> From: concurrency-interest-bounces@...
> [mailto:concurrency-interest-bounces@...] On Behalf Of raghuram
> nidagal
> Sent: Tuesday, December 08, 2009 6:12 AM
> To: concurrency-interest@...
> Subject: [concurrency-interest] out of order execution on uniprocessor
>
> Hi,
> Is "out of order execution" relevant in case of a single processor. I see
> the following extracts relating to single processors. Would appreciate if
> somebody could clarify
> what can be expected in a single processor case.
> Discussing this in terms of caches, it may sound as if these issues only
> affect multiprocessor machines. However, the reordering effects can be
> easily seen on a single processor. It is not possible, for example, for the
> compiler to move your code before an acquire or after a release. When we say
> that acquires and releases act on caches, we are using shorthand for a
> number of possible effects.
> http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering
>
> If you are generating code that is guaranteed to only run on a uniprocessor,
> then you can probably skip the rest of this section. Because uniprocessors
> preserve apparent sequential consistency, you never need to issue barriers
> unless object memory is somehow shared with asynchrononously accessible IO
> memory. This might occur with specially mapped java.nio buffers, but
> probably only in ways that affect internal JVM support code, not Java code.
> Also, it is conceivable that some special barriers would be needed if
> context switching doesn't entail sufficient synchronization.
>
> http://gee.cs.oswego.edu/dl/jmm/cookbook.html
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: out of order execution on uniprocessor

2009-12-08T10:37:36Z

If you are writing Java code, it doesn't matter whether you're on a uniprocessor. The hardware generally won't visibly reorder memory accesses on a uniprocessor, but the compiler still will. And you'd be hard pressed to tell the difference.

If you are building a JVM, then it does matter. Since the hardware doesn't reorder, you can take some shortcuts.

Both of the excerpts below are correct, but they're targeting a different audience.

Hans

P.S. I do think there are a few statements in the cookbook that are in need of an update. The ppc and pa-risc situations are more complex than what's stated there. (The PA_RISC recipe works for actual hardware, but I think the emulator on Itanium follows the rules inthe manual, which allow more reordering. For PPC, I think the recipes for sequentially consistent operations in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html also apply to Java volatiles and are more accurate.)

From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...] On Behalf Of raghuram nidagal
Sent: Tuesday, December 08, 2009 6:12 AM
To: concurrency-interest@...
Subject: [concurrency-interest] out of order execution on uniprocessor

Hi,
Is "out of order execution" relevant in case of a single processor. I see the following extracts relating to single processors. Would appreciate if somebody could clarify

what can be expected in a single processor case.

Discussing this in terms of caches, it may sound as if these issues only affect multiprocessor machines. However, the reordering effects can be easily seen on a single processor. It is not possible, for example, for the compiler to move your code before an acquire or after a release. When we say that acquires and releases act on caches, we are using shorthand for a number of possible effects.
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering

If you are generating code that is guaranteed to only run on a uniprocessor, then you can probably skip the rest of this section. Because uniprocessors preserve apparent sequential consistency, you never need to issue barriers unless object memory is somehow shared with asynchrononously accessible IO memory. This might occur with specially mapped java.nio buffers, but probably only in ways that affect internal JVM support code, not Java code. Also, it is conceivable that some special barriers would be needed if context switching doesn't entail sufficient synchronization.

http://gee.cs.oswego.edu/dl/jmm/cookbook.html

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

out of order execution on uniprocessor

2009-12-08T06:12:14Z

Hi,

Is "out of order execution" relevant in case of a single processor. I see the following extracts relating to single processors. Would appreciate if somebody could clarify

what can be expected in a single processor case.

Discussing this in terms of caches, it may sound as if these issues only affect multiprocessor machines. However, the reordering effects can be easily seen on a single processor. It is not possible, for example, for the compiler to move your code before an acquire or after a release. When we say that acquires and releases act on caches, we are using shorthand for a number of possible effects.
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering

If you are generating code that is guaranteed to only run on a uniprocessor, then you can probably skip the rest of this section. Because uniprocessors preserve apparent sequential consistency, you never need to issue barriers unless object memory is somehow shared with asynchrononously accessible IO memory. This might occur with specially mapped java.nio buffers, but probably only in ways that affect internal JVM support code, not Java code. Also, it is conceivable that some special barriers would be needed if context switching doesn't entail sufficient synchronization.

http://gee.cs.oswego.edu/dl/jmm/cookbook.html

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Seeking Interruption Rule Clarification

2009-12-06T19:23:35Z

Will,

> But it gets even more complicated, because we could also have the
> following actual execution sequence (ie, assume that this is the
> "real" global execution sequence, after any reorderings) between
> just 2 threads, T1 and T3:
>
> 1) T3 has just called Thread.sleep(10000)
> 2) 2 secs later, T1 calls T3.interrupt().
> 3) 2 secs later, T1 executes the statement "x = 5" (stores a
> value into a mutable shared var)
> 4) 2 secs later, T1 again calls T3.interrupt()
> 5) Now T3's Thread.sleep(10000) call (from step #1) returns, and
> T3 calls T3.interrupted() and detects the interrupt.
> 6) T3 performs a read on var x
>
> In this case, the same thread T1 made 2 calls to T3.interrupt()
> (in steps #2 & #4), but only the call from step #2 is the one
> that caused the actual state change to T3's interrupt flag, so
> supposedly this is the only state change that T3 "detected". Does
> that mean that there's only a HB left edge from the execution of
> T1's first T3.interrupt() call rather than from T1's second
> T3.interrupt() call? If that's true, then it seems that there can
> be no (transitive) HB edge between the write of var x in T1 and
> the read of var x in T3, in which case the value "5" might not be
> visible to T3's read, right?

Maybe. The problem is that JMM rule is really only considering the case
where the actual interrupt state changes. In the scenario given the second
interrupt call might be implemented as a no-op if the system can see that
the target is already in the interrupted state. In practice on Hotspot it
isn't a complete no-op so you're in fact likely to get the necessary memory
synchronization to see the value "5".

The JMM would have to specify the interaction here in a lot more detail to
be able to reason in the abstract about what is guaranteed in this case.
Even treating the interrupted state as a volatile does not specify it
precisely enough as you need to know if interrupt() is required to always
write to the volatile or can elide it if it sees the thread is already
interrupted.

Cheers,
David Holmes

> Thank you. I appreciate your help in clarifying.
>
> Cheers,
> Will

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Task Queue ordering

2009-12-04T23:25:42Z

Ken,

I'm imagining a serial executor per client:

ExecutorService pool = Executors.newCachedThreadPool();

Executor execA = new SerialExecutor(pool);
Executor execB = new SerialExecutor(pool);

SerialTask task1 = new SerialTask("client-a", 10);
SerialTask task2 = new SerialTask("client-a", 10);
SerialTask task3 = new SerialTask("client-a", 10);
SerialTask task4 = new SerialTask("client-b", 2000);
SerialTask task5 = new SerialTask("client-b", 4000);
SerialTask task6 = new SerialTask("client-a", 10);

execA.execute(task1);
execA.execute(task2);
execA.execute(task3);
execB.execute(task4);
execB.execute(task5);
execA.execute(task6);

--Joe

On Fri, Dec 4, 2009 at 9:51 PM, Ken--@... wrote:

Dear Joe,

Sorry I cannot under how to achieve it. I have tasks to be submitted in
order (task1 to task6) like this:

public class SerialTask implements Runnable {
private String client = null;
private long sleep = 0;
public SerialTask(String client, long sleep){
this.client = client;
this.sleep = sleep;
}
public void run() {
try {Thread.sleep(sleep);} catch (Exception e) {}
String msg = "Task ID = " + client + ", sleep = " + sleep;
System.out.println(msg);
}
}

SerialTask task1 = new SerialTask("client-a", 10);
SerialTask task2 = new SerialTask("client-a", 10);
SerialTask task3 = new SerialTask("client-a", 10);
SerialTask task4 = new SerialTask("client-b", 2000);
SerialTask task5 = new SerialTask("client-b", 4000);
SerialTask task6 = new SerialTask("client-a", 10);

How can I make use of SerialExecutor to execute client's task in order? I
expected client-a's tasks can be finished in 40 mills and tasks are run in
serial. and after around (2000 + 4000 - 40) mills, all client-b tasks are
finished.

Regards,
Ken

Joe Bowbeer wrote:
>
> If each client's tasks are executed sequentially, you can use a
> SerialExecutor per client. See the "SerialExecutor" example in the
> Executor
> javadoc. Each client's executor would delegate to the shared thread pool
> executor.
>
> If all tasks can execute in concurrently, but you want to retire them in
> order, I think there was a useful discussion about this in June '08.
> Search for "Out-of-order execution, in-order retirement".
>
> (The suggestion was to queue the Futures when the Callables are submitted,
> and retire the tasks in the order they were enqueued.)
>
> --Joe
>
> On Wed, Dec 2, 2009 at 6:32 PM, Ken--@... wrote:
>
>>
>> Hi All,
>>
>> I have a Task Queue (ArrayBlockingQueue) with single thread for client's
>> task processing. For same client, I have to guarantee the ordering of
>> task
>> results as I need the result of previous task to perform next task of the
>> same client. It's work for ArrayBlockQueue with single thread as it's
>> always
>> FIFO.
>>
>> My question is, how to enable multi threads (like ThreadPoolExecutor) for
>> queue but maintaining the ordering of same client's tasks? I tried
>> PriorityBlockingQueue but it just ensure tasks are started in order.
>>
>> Any solution? Please help.
>>
>> Thanks and Best Regards,
>> Ken
>>
>>

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Task Queue ordering

2009-12-04T21:51:22Z

Dear Joe,

Sorry I cannot under how to achieve it. I have tasks to be submitted in order (task1 to task6) like this:

public class SerialTask implements Runnable {
private String client = null;
private long sleep = 0;
public SerialTask(String client, long sleep){
this.client = client;
this.sleep = sleep;
}
public void run() {
try {Thread.sleep(sleep);} catch (Exception e) {}
String msg = "Task ID = " + client + ", sleep = " + sleep;
System.out.println(msg);
}
}

SerialTask task1 = new SerialTask("client-a", 10);
SerialTask task2 = new SerialTask("client-a", 10);
SerialTask task3 = new SerialTask("client-a", 10);
SerialTask task4 = new SerialTask("client-b", 2000);
SerialTask task5 = new SerialTask("client-b", 4000);
SerialTask task6 = new SerialTask("client-a", 10);

How can I make use of SerialExecutor to execute client's task in order? I expected client-a's tasks can be finished in 40 mills and tasks are run in serial. and after around (2000 + 4000 - 40) mills, all client-b tasks are finished.

Regards,
Ken

Joe Bowbeer wrote:

If each client's tasks are executed sequentially, you can use a
SerialExecutor per client. See the "SerialExecutor" example in the Executor
javadoc. Each client's executor would delegate to the shared thread pool
executor.

If all tasks can execute in concurrently, but you want to retire them in
order, I think there was a useful discussion about this in June '08.
Search for "Out-of-order execution, in-order retirement".

(The suggestion was to queue the Futures when the Callables are submitted,
and retire the tasks in the order they were enqueued.)

--Joe

On Wed, Dec 2, 2009 at 6:32 PM, Ken--@newsgroupstats.hk wrote:

>
> Hi All,
>
> I have a Task Queue (ArrayBlockingQueue) with single thread for client's
> task processing. For same client, I have to guarantee the ordering of task
> results as I need the result of previous task to perform next task of the
> same client. It's work for ArrayBlockQueue with single thread as it's
> always
> FIFO.
>
> My question is, how to enable multi threads (like ThreadPoolExecutor) for
> queue but maintaining the ordering of same client's tasks? I tried
> PriorityBlockingQueue but it just ensure tasks are started in order.
>
> Any solution? Please help.
>
> Thanks and Best Regards,
> Ken
>
>

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Seeking Interruption Rule Clarification

2009-12-04T12:53:31Z

If you believe that the volatile case is equivalent, then the second bullet under 17.4.4 (JLS 3rd edition, http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4.4) makes it clear that any prior (in a total synchronization order) write of a volatile flag synchronizes with any later read of the synchronization variable.

In that case, both happens before edges inthe original question exist.

I'm inclined to read the last bullet in that list as confirming this interpretation.

Hans

From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...] On Behalf Of Joe Bowbeer
Sent: Friday, December 04, 2009 11:56 AM
To: concurrency-interest@...
Subject: Re: [concurrency-interest] Seeking Interruption Rule Clarification

I think you can reason effectively about this by replacing the interrupted flag with a volatile boolean flag.

T3: T3.flag = false
T1: T3.flag = true
T2: T3.flag = true
T3: if T3.flag then ...

The right answer, I think, is that the write to the volatile will always "happen" (unless the compiler can deduce that a concurrent read will never happen). However, I'm not sure how or if the JMM specifies this.

--Joe

On Fri, Dec 4, 2009 at 11:22 AM, Will McQueen wrote:

Hi,

On p341 of JCIP, the Interruption Rule states:
"A thread calling interrupt on another thread happens-before the interrupted thread detects the interrupt (either by having InterruptedException thrown, or invoking isInterrupted or interrupted)"

I'm a little unclear on the specifics. Suppose that we have:
Threads T1, T2, and T3 are alive and the interrupt flag is clear. T3 is executing in a loop, where it does Thread.sleep(10000) and then calls T3.interrupted() to check+clear the flag status.

And suppose that we have the following global execution sequence:
1) T3 has just called Thread.sleep(10000)
2) 2 secs later, T1 calls T3.interrupt().
3) Another 2 secs later, T2 calls T3.interrupt().
4) Now T3's Thread.sleep(10000) call (from step #1) returns, and T3 calls T3.interrupted() and detects the interrupt.

In this case which of the following statements can we claim as true?
1) There's a HB edge from T1's T3.interrupt() call to T3's T3.interrupt() call.
2) There's a HB edge from T2's T3.interrupt() call to T3's T3.interrupt() call.

I would guess that we can only claim #1, because T1 is the thread that caused T3's interrupt flag state to change state from false to true. T2's call to T3.interrupt() did not cause a state change to T3's interrupt flag because it was already true before T2 called T3.interrupt(). My assumption can be summed-up as:

"The Interruption Rule results in a HB edge from T1's T3.interrupt() call to T3's T3.interrupted() call, only if T1 was the thread responsible for the state change to T3's interrupt flag".

But it gets even more complicated, because we could also have the following actual execution sequence (ie, assume that this is the "real" global execution sequence, after any reorderings) between just 2 threads, T1 and T3:

1) T3 has just called Thread.sleep(10000)
2) 2 secs later, T1 calls T3.interrupt().
3) 2 secs later, T1 executes the statement "x = 5" (stores a value into a mutable shared var)
4) 2 secs later, T1 again calls T3.interrupt()
5) Now T3's Thread.sleep(10000) call (from step #1) returns, and T3 calls T3.interrupted() and detects the interrupt.
6) T3 performs a read on var x

In this case, the same thread T1 made 2 calls to T3.interrupt() (in steps #2 & #4), but only the call from step #2 is the one that caused the actual state change to T3's interrupt flag, so supposedly this is the only state change that T3 "detected". Does that mean that there's only a HB left edge from the execution of T1's first T3.interrupt() call rather than from T1's second T3.interrupt() call? If that's true, then it seems that there can be no (transitive) HB edge between the write of var x in T1 and the read of var x in T3, in which case the value "5" might not be visible to T3's read, right?

Thank you. I appreciate your help in clarifying.

Cheers,
Will

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Seeking Interruption Rule Clarification

2009-12-04T11:56:22Z

I think you can reason effectively about this by replacing the interrupted flag with a volatile boolean flag.

T3: T3.flag = false
T1: T3.flag = true
T2: T3.flag = true
T3: if T3.flag then ...

The right answer, I think, is that the write to the volatile will always "happen" (unless the compiler can deduce that a concurrent read will never happen). However, I'm not sure how or if the JMM specifies this.

--Joe

On Fri, Dec 4, 2009 at 11:22 AM, Will McQueen wrote:

Hi,

On p341 of JCIP, the Interruption Rule states:
"A thread calling interrupt on another thread happens-before the interrupted thread detects the interrupt (either by having InterruptedException thrown, or invoking isInterrupted or interrupted)"

I'm a little unclear on the specifics. Suppose that we have:
Threads T1, T2, and T3 are alive and the interrupt flag is clear. T3 is executing in a loop, where it does Thread.sleep(10000) and then calls T3.interrupted() to check+clear the flag status.

And suppose that we have the following global execution sequence:
1) T3 has just called Thread.sleep(10000)
2) 2 secs later, T1 calls T3.interrupt().
3) Another 2 secs later, T2 calls T3.interrupt().
4) Now T3's Thread.sleep(10000) call (from step #1) returns, and T3 calls T3.interrupted() and detects the interrupt.

In this case which of the following statements can we claim as true?
1) There's a HB edge from T1's T3.interrupt() call to T3's T3.interrupt() call.
2) There's a HB edge from T2's T3.interrupt() call to T3's T3.interrupt() call.

I would guess that we can only claim #1, because T1 is the thread that caused T3's interrupt flag state to change state from false to true. T2's call to T3.interrupt() did not cause a state change to T3's interrupt flag because it was already true before T2 called T3.interrupt(). My assumption can be summed-up as:

"The Interruption Rule results in a HB edge from T1's T3.interrupt() call to T3's T3.interrupted() call, only if T1 was the thread responsible for the state change to T3's interrupt flag".

But it gets even more complicated, because we could also have the following actual execution sequence (ie, assume that this is the "real" global execution sequence, after any reorderings) between just 2 threads, T1 and T3:

1) T3 has just called Thread.sleep(10000)
2) 2 secs later, T1 calls T3.interrupt().
3) 2 secs later, T1 executes the statement "x = 5" (stores a value into a mutable shared var)
4) 2 secs later, T1 again calls T3.interrupt()
5) Now T3's Thread.sleep(10000) call (from step #1) returns, and T3 calls T3.interrupted() and detects the interrupt.
6) T3 performs a read on var x

In this case, the same thread T1 made 2 calls to T3.interrupt() (in steps #2 & #4), but only the call from step #2 is the one that caused the actual state change to T3's interrupt flag, so supposedly this is the only state change that T3 "detected". Does that mean that there's only a HB left edge from the execution of T1's first T3.interrupt() call rather than from T1's second T3.interrupt() call? If that's true, then it seems that there can be no (transitive) HB edge between the write of var x in T1 and the read of var x in T3, in which case the value "5" might not be visible to T3's read, right?

Thank you. I appreciate your help in clarifying.

Cheers,
Will

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Seeking Interruption Rule Clarification

2009-12-04T11:22:48Z

Hi,

On p341 of JCIP, the Interruption Rule states:
"A thread calling interrupt on another thread happens-before the interrupted thread detects the interrupt (either by having InterruptedException thrown, or invoking isInterrupted or interrupted)"

I'm a little unclear on the specifics. Suppose that we have:
Threads T1, T2, and T3 are alive and the interrupt flag is clear. T3 is executing in a loop, where it does Thread.sleep(10000) and then calls T3.interrupted() to check+clear the flag status.

And suppose that we have the following global execution sequence:
1) T3 has just called Thread.sleep(10000)
2) 2 secs later, T1 calls T3.interrupt().
3) Another 2 secs later, T2 calls T3.interrupt().
4) Now T3's Thread.sleep(10000) call (from step #1) returns, and T3 calls T3.interrupted() and detects the interrupt.

In this case which of the following statements can we claim as true?
1) There's a HB edge from T1's T3.interrupt() call to T3's T3.interrupt() call.
2) There's a HB edge from T2's T3.interrupt() call to T3's T3.interrupt() call.

I would guess that we can only claim #1, because T1 is the thread that caused T3's interrupt flag state to change state from false to true. T2's call to T3.interrupt() did not cause a state change to T3's interrupt flag because it was already true before T2 called T3.interrupt(). My assumption can be summed-up as:

"The Interruption Rule results in a HB edge from T1's T3.interrupt() call to T3's T3.interrupted() call, only if T1 was the thread responsible for the state change to T3's interrupt flag".

But it gets even more complicated, because we could also have the following actual execution sequence (ie, assume that this is the "real" global execution sequence, after any reorderings) between just 2 threads, T1 and T3:

1) T3 has just called Thread.sleep(10000)
2) 2 secs later, T1 calls T3.interrupt().
3) 2 secs later, T1 executes the statement "x = 5" (stores a value into a mutable shared var)
4) 2 secs later, T1 again calls T3.interrupt()
5) Now T3's Thread.sleep(10000) call (from step #1) returns, and T3 calls T3.interrupted() and detects the interrupt.
6) T3 performs a read on var x

In this case, the same thread T1 made 2 calls to T3.interrupt() (in steps #2 & #4), but only the call from step #2 is the one that caused the actual state change to T3's interrupt flag, so supposedly this is the only state change that T3 "detected". Does that mean that there's only a HB left edge from the execution of T1's first T3.interrupt() call rather than from T1's second T3.interrupt() call? If that's true, then it seems that there can be no (transitive) HB edge between the write of var x in T1 and the read of var x in T3, in which case the value "5" might not be visible to T3's read, right?

Thank you. I appreciate your help in clarifying.

Cheers,
Will

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Gaurav Kant Tyagi is out of the office.

2009-12-03T14:31:16Z

I will be out of the office starting 11/27/2009 and will not return until
12/07/2009.

I will respond to your message when I return.

CST coverage: Yogesh Kulkarni is my back-up for any project related
request.
IST coverage: Ashish Birla will be my back up for project related
activities.

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Task Queue ordering

2009-12-02T19:16:30Z

If each client's tasks are executed sequentially, you can use a SerialExecutor per client. See the "SerialExecutor" example in the Executor javadoc. Each client's executor would delegate to the shared thread pool executor.

If all tasks can execute in concurrently, but you want to retire them in order, I think there was a useful discussion about this in June '08. Search for "Out-of-order execution, in-order retirement".

(The suggestion was to queue the Futures when the Callables are submitted, and retire the tasks in the order they were enqueued.)

--Joe

On Wed, Dec 2, 2009 at 6:32 PM, Ken--@... wrote:

Hi All,

I have a Task Queue (ArrayBlockingQueue) with single thread for client's
task processing. For same client, I have to guarantee the ordering of task
results as I need the result of previous task to perform next task of the
same client. It's work for ArrayBlockQueue with single thread as it's always
FIFO.

My question is, how to enable multi threads (like ThreadPoolExecutor) for
queue but maintaining the ordering of same client's tasks? I tried
PriorityBlockingQueue but it just ensure tasks are started in order.

Any solution? Please help.

Thanks and Best Regards,
Ken

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Task Queue ordering

2009-11-30T19:23:47Z

Hi All,

I have a Task Queue (ArrayBlockingQueue) with single thread for client's task processing. For same client, I have to guarantee the ordering of task results as I need the result of previous task to perform next task of the same client. It's work for ArrayBlockQueue with single thread as it's always FIFO.

My question is, how to enable multi threads (like ThreadPoolExecutor) for queue but maintaining the ordering of same client's tasks? I tried PriorityBlockingQueue but it just ensure tasks are started in order.

Any solution? Please help.

Thanks and Best Regards,
Ken

Re: Concurrent Bidirectional Map

2009-11-22T21:28:58Z

On Sun, Nov 22, 2009 at 20:25, Norman Elton <normelton@...> wrote:

>> Suppose
>> thread 1 is trying to set k -> v1
>> while
>> thread 2 is trying to set k -> v2
>>
>> Because the updates of the two maps are independent,
>> and you can't control the scheduler, there is a risk of
>> ending up with
>> k -> v1
>> in the first map, and
>> v2 -> k
>> in the reverse map
>> in the quiescent state.
>
> I've synchronized the put() methods in both directions back to a
> single lock object, so one thread would block while the other
> completes its update. Correct me if I'm wrong, this is definitely my
> knowledge of the inner workings synchronization starts to get fuzzy.

OK, I think you're mostly fine.
An observer might be able to see an "impossible"
sequence, but users are unlikely to care.

E.g. Perhaps it's an invariant that some key is
only ever modified by having its value incremented,
perhaps by calls to replace(key, value, value+1).
but another thread can observe apparent violations
of monotonicity
k -> 0
k -> 1
reverse map 0 -> k

Martin
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T20:25:50Z

> Suppose
> thread 1 is trying to set k -> v1
> while
> thread 2 is trying to set k -> v2
>
> Because the updates of the two maps are independent,
> and you can't control the scheduler, there is a risk of
> ending up with
> k -> v1
> in the first map, and
> v2 -> k
> in the reverse map
> in the quiescent state.

I've synchronized the put() methods in both directions back to a
single lock object, so one thread would block while the other
completes its update. Correct me if I'm wrong, this is definitely my
knowledge of the inner workings synchronization starts to get fuzzy.

Norman
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T20:01:07Z

On Sun, Nov 22, 2009 at 18:37, Norman Elton <normelton@...> wrote:

>> From how you describe it, it sounds like there is no consistency issue. If
>> no thread can ever expect to find that:
>>
>> v->k => k->v
>>
>> then the fact that the above can fail to hold during a modification to the
>> bi-map seems of little consequence.
>
> Just to clarify... yes, at any given instant, k -> v does imply v ->
> k. But there is no way, that I can see, to atomically access both
> get(k) and get(v).

Suppose
thread 1 is trying to set k -> v1
while
thread 2 is trying to set k -> v2

Because the updates of the two maps are independent,
and you can't control the scheduler, there is a risk of
ending up with
k -> v1
in the first map, and
v2 -> k
in the reverse map
in the quiescent state.

Martin
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Performance of ReentrantReadWriteLock

2009-11-22T19:53:51Z

Some thoughts:

RRWL has a bunch of overhead related to
keeping track of read hold state, that could
be removed to get something faster but less
debuggable. I've wanted to do something
in this area.

I'd be interested in perf results when you have
lots of writes. What's the overhead of RRWL
over RL when only the writelock is ever acquired?

Do you actually have enough processors to keep
your 5 threads busy?

writing micro-benchmarks is known to be hard,
and for concurrency primitives especially so.
Perhaps you could share your micro-benchmark?

RRWL has seen some implementation improvements
post-JDK6. Try the JDK7, JDK6, JDK5 implementations
with a jdk7 hotspot, perhaps.

Martin

On Wed, Nov 18, 2009 at 20:46, Norman Elton <normelton@...> wrote:

> I've done some very basic testing of a ReentrantReadWriteLock vs.
> synchronized. I fired up five threads, each of which is accessing a
> shared Map<Integer,Integer>. At first, I did 99% read operations, then
> 100% read operations. Initial testing, with no locking or
> synchronization, proved about 8M operations per second per thread.
> Super.
>
> Then I tested synchronizing the get() and put() methods. Performance
> dropped to about 700K operations per second. Synchronization obviously
> has a large overhead.
>
> Strange thing is, the ReentrantReadWriteLock performed just about as
> well. Even in a 100% read environment, where I would think threads
> would never have to block for one another.
>
> Am I missing something here? Shouldn't I be seeing significantly
> better numbers for the ReentrantReadWriteLock? Presumably, it's
> allowing multiple threads to hit the hash at the same time. I would
> expect numbers somewhere between the synchronizing hash and the
> completely untouched HashMap.
>
> Thoughts? Thanks!
>
> Norman
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T18:53:27Z

Fwiw, I also endorse the view that a Copy-on-write wrapper around guava-libraries BiMap would be more performant (and simpler to write too).

Dhanji.

On Sun, Nov 22, 2009 at 6:37 PM, Norman Elton <normelton@...> wrote:

> From how you describe it, it sounds like there is no consistency issue. If
> no thread can ever expect to find that:
>
> v->k => k->v
>
> then the fact that the above can fail to hold during a modification to the
> bi-map seems of little consequence.

Just to clarify... yes, at any given instant, k -> v does imply v ->
k. But there is no way, that I can see, to atomically access both
get(k) and get(v).

Thanks all,

Norman
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T18:37:36Z

> From how you describe it, it sounds like there is no consistency issue. If
> no thread can ever expect to find that:
>
> v->k => k->v
>
> then the fact that the above can fail to hold during a modification to the
> bi-map seems of little consequence.

Just to clarify... yes, at any given instant, k -> v does imply v ->
k. But there is no way, that I can see, to atomically access both
get(k) and get(v).

Thanks all,

Norman
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T17:30:29Z

Norman,

>From how you describe it, it sounds like there is no consistency issue. If
no thread can ever expect to find that:

v->k => k->v

then the fact that the above can fail to hold during a modification to the
bi-map seems of little consequence.

Cheers,
David

> -----Original Message-----
> From: concurrency-interest-bounces@...
> [mailto:concurrency-interest-bounces@...]On Behalf Of Norman
> Elton
> Sent: Monday, 23 November 2009 11:19 AM
> To: concurrency-interest@...
> Subject: Re: [concurrency-interest] Concurrent Bidirectional Map
>
>
> > Yea, the update to both maps is not atomic because reader threads can
> > interleave between writes to either map. Technically, you won't
> corrupt the
> > map (unlike in the case of a regular HashMap), but that depends
> on what your
> > definition of corruption is (as David says). A read from the
> value->key map
> > can be inconsistent with a put to the key->value map.
>
> Thanks David & Dhanji for your thinking on this.
>
> I realize that if two threads hit the map at the same time, one doing
> a look-by-key and another doing a lookup-by-value, while a third
> thread is doing an update, it is possible the two readers will see
> different pairings. But, is this a problem? They are two separate
> threads. How should they expect to be simultaneously seeing the same
> "state" of the map?
>
> Likewise, a single thread that does a lookup-by-key, followed by a
> lookup-by-value, should expect to get two different results, since
> it's entirely feasible that another thread updates the map between the
> two reads.
>
> My implementation of the BiMap doesn't have any unsynchronized methods
> (I think!) that refer to both maps. All of the reader methods use a
> single of the two CHMs, which represent a valid "snapshot" of the map
> when referenced.
>
> Thanks again, all, for your help on this! Let me know if my reasoning
> is flawed, I've enjoyed thinking though this :-).
>
> Norman
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T17:19:18Z

> Yea, the update to both maps is not atomic because reader threads can
> interleave between writes to either map. Technically, you won't corrupt the
> map (unlike in the case of a regular HashMap), but that depends on what your
> definition of corruption is (as David says). A read from the value->key map
> can be inconsistent with a put to the key->value map.

Thanks David & Dhanji for your thinking on this.

I realize that if two threads hit the map at the same time, one doing
a look-by-key and another doing a lookup-by-value, while a third
thread is doing an update, it is possible the two readers will see
different pairings. But, is this a problem? They are two separate
threads. How should they expect to be simultaneously seeing the same
"state" of the map?

Likewise, a single thread that does a lookup-by-key, followed by a
lookup-by-value, should expect to get two different results, since
it's entirely feasible that another thread updates the map between the
two reads.

My implementation of the BiMap doesn't have any unsynchronized methods
(I think!) that refer to both maps. All of the reader methods use a
single of the two CHMs, which represent a valid "snapshot" of the map
when referenced.

Thanks again, all, for your help on this! Let me know if my reasoning
is flawed, I've enjoyed thinking though this :-).

Norman
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T15:40:04Z

Norman,

I have found that for this kind of application (read-mostly) a
copy-on-write approach can work very well (depending on the size of the
structure as the write is O(n)). We use a CopyOnWriteMap[1] that follows
a similar scheme to the j.u.c CopyOnWriteArrayList and have found that
its read performance in highly contended reads is excellent as it is
completely lock-free, whereas CHM will still do some locking on its
internal buckets.

Implementing something similar for google-collections BiMap would not be
difficult (the algorithm is very simple), the only problem being that
the g.c. Immutable*.Builder implementations don't support removal[2]
unfortunately, making a COW* implementation that uses them internally
require two copies per write in the remove/replace cases.

cheers,
jed.

[1]
https://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/CopyOnWriteMap.java?r=2602
[2] http://code.google.com/p/google-collections/issues/detail?id=279

Norman Elton wrote:

> Dhanji,
>
> Thanks for dedicating some brain-cells to looking at this.
>
>
>> Unfortunately, if you synchronize put() and remove() you lose the
>> concurrency benefits of CHM. All threads will serialize behind the put lock.
>>
>
> Yep. My application is 99% reads and 1% writes, so I can tolerate
> single-threading put() and remove() operations. One major benefit that
> does remain; however, is that I don't have to worry about concurrent
> modification exceptions when iterating through the map members.
>
> I would love someone with more concurrency kung-fu to implement a real
> BiMap, so that I wouldn't have to rely on synchronization.
>
>
>> Also, in your implementation, in order for the bi-map-put to be perceived
>> atomically, you would have to synchronize the get method as well =(
>>
>
> This is where I'm a little perplexed. I've synchronized any write
> methods, so that the two CHMs stay "in synch". Any read operations, as
> I see it, should be safe to fall through to the primary CHM without
> extra synchronization. If one thread is updating the map while another
> is reading, the reading thread will either get the new or the old
> value, but we shouldn't get any exceptions or end up with inconsistent
> CHMs.
>
> Or am I misunderstanding something?
>
> Thanks again,
>
> Norman
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T15:11:57Z

On Sun, Nov 22, 2009 at 2:52 PM, David Holmes <davidcholmes@...> wrote:

Norman,

Norman Elton writes:

> Dhanji R. Prasanna writes:
> > Also, in your implementation, in order for the bi-map-put to be
> > perceived atomically, you would have to synchronize the get
> > method as well =(
>
> This is where I'm a little perplexed. I've synchronized any write
> methods, so that the two CHMs stay "in synch". Any read operations, as
> I see it, should be safe to fall through to the primary CHM without
> extra synchronization. If one thread is updating the map while another
> is reading, the reading thread will either get the new or the old
> value, but we shouldn't get any exceptions or end up with inconsistent
> CHMs.
>
> Or am I misunderstanding something?

Your reader thread can access the map while only one of the associations is
in effect.

Yea, the update to both maps is not atomic because reader threads can interleave between writes to either map. Technically, you won't corrupt the map (unlike in the case of a regular HashMap), but that depends on what your definition of corruption is (as David says). A read from the value->key map can be inconsistent with a put to the key->value map.

Dhanji.

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T14:52:52Z

Norman,

Norman Elton writes:

> Dhanji R. Prasanna writes:
> > Also, in your implementation, in order for the bi-map-put to be
> > perceived atomically, you would have to synchronize the get
> > method as well =(
>
> This is where I'm a little perplexed. I've synchronized any write
> methods, so that the two CHMs stay "in synch". Any read operations, as
> I see it, should be safe to fall through to the primary CHM without
> extra synchronization. If one thread is updating the map while another
> is reading, the reading thread will either get the new or the old
> value, but we shouldn't get any exceptions or end up with inconsistent
> CHMs.
>
> Or am I misunderstanding something?

Your reader thread can access the map while only one of the associations is
in effect. Whether that can cause a problem in practice depends on the exact
semantics of the bi-map and how it is used. If you add the value->key
mapping before the key->value mapping (and remove in opposite order) then it
will mitigate the ability to see inconsistency - assuming you always lookup
by key, not value.

David Holmes

> Thanks again,
>
> Norman
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-22T11:54:28Z

Dhanji,

Thanks for dedicating some brain-cells to looking at this.

> Unfortunately, if you synchronize put() and remove() you lose the
> concurrency benefits of CHM. All threads will serialize behind the put lock.

Yep. My application is 99% reads and 1% writes, so I can tolerate
single-threading put() and remove() operations. One major benefit that
does remain; however, is that I don't have to worry about concurrent
modification exceptions when iterating through the map members.

I would love someone with more concurrency kung-fu to implement a real
BiMap, so that I wouldn't have to rely on synchronization.

> Also, in your implementation, in order for the bi-map-put to be perceived
> atomically, you would have to synchronize the get method as well =(

This is where I'm a little perplexed. I've synchronized any write
methods, so that the two CHMs stay "in synch". Any read operations, as
I see it, should be safe to fall through to the primary CHM without
extra synchronization. If one thread is updating the map while another
is reading, the reading thread will either get the new or the old
value, but we shouldn't get any exceptions or end up with inconsistent
CHMs.

Or am I misunderstanding something?

Thanks again,

Norman
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: park and unpark low-level details

2009-11-22T09:36:25Z

On Fri, Nov 20, 2009 at 10:41, Andrew Haley <aph@...> wrote:

Dave Dice wrote:

>> What do you man by this? I guess there's a nice way to map park and
>> unpark onto low-level NPTL primitives (futexes, perhaps?) Did you
>> have a sketch of a design for that?
>

> We preferred to use more standardized interfaces. I experimented
> with using futexes instead of the usual condvar-mutex-flag tuple but
> it wasn't particularly better.

I'm not surprised. I did some profiling, and even with quite heavily
contended locks the time spent in park and unpark is often down in
the noise. Amazing, really. :-)

Coincidentally, there's an article on futexes here:

http://lwn.net/Articles/360699/

Regarding using standard interfaces:

---
Man pages: The current man pages do not include some of the new futex operations. They suggest a policy for the value of the futex which has led to some confusion regarding usage of futexes. Worst of all, the user space futex() definition has been removed from /usr/include/linux/futex.h, rendering the man pages not only incomplete, but also inaccurate. Users of futexes must use the syscall interface directly.
---

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: Concurrent Bidirectional Map

2009-11-21T20:28:28Z

Unfortunately, if you synchronize put() and remove() you lose the concurrency benefits of CHM. All threads will serialize behind the put lock. Also, in your implementation, in order for the bi-map-put to be perceived atomically, you would have to synchronize the get method as well =(

It is an interesting use case, however.

my 2c.

Dhanji.

On Sun, Nov 22, 2009 at 2:54 PM, Norman Elton <normelton@...> wrote:

Let me start by saying that I am, by no means, a concurrency guru. But
I did have a use for a concurrent bidirectional map, one that
maintains key-to-value and value-to-key uniqueness. I whipped up a
quick implementation of ConcurrentBiMap built around two
ConcurrentHashMaps. The BiMap implements Map<K,V>, with the single
extra method inverse(), which returns a Map<V,K>.

I basically synchronized all the modifying methods (clear, put,
remove, etc) so that I could safely change both maps atomically. All
other methods are unsynchronized. The methods that would normally
return modifiable Sets (entrySet, values, keySet) return unmodifiable
versions of their "normal" values, since I have not yet come up with a
way to allow the user to atomically remove a value from such a set.

I'll attach both the code and a fairly extensive JUnit test case. A
few questions remain:

- Have I reinvented the wheel? Is there already a good / better
implementation of a ConcurrentBiMap?

- Is there a good way to test the atomicity of code? I could fire up
multiple threads and let them simultaneously hammer away at a shared
hash, but I'm not sure this would be a good reproducible test case.

- Can anyone think of a way to allow the three Set methods (entrySet,
keySet, values) to return modifiable values? That is, if you remove an
item from them, they atomically affect the original BiMap.

Thanks for any pointers,

Norman

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Concurrent Bidirectional Map

2009-11-21T19:54:15Z

Let me start by saying that I am, by no means, a concurrency guru. But
I did have a use for a concurrent bidirectional map, one that
maintains key-to-value and value-to-key uniqueness. I whipped up a
quick implementation of ConcurrentBiMap built around two
ConcurrentHashMaps. The BiMap implements Map<K,V>, with the single
extra method inverse(), which returns a Map<V,K>.

I basically synchronized all the modifying methods (clear, put,
remove, etc) so that I could safely change both maps atomically. All
other methods are unsynchronized. The methods that would normally
return modifiable Sets (entrySet, values, keySet) return unmodifiable
versions of their "normal" values, since I have not yet come up with a
way to allow the user to atomically remove a value from such a set.

I'll attach both the code and a fairly extensive JUnit test case. A
few questions remain:

- Have I reinvented the wheel? Is there already a good / better
implementation of a ConcurrentBiMap?

- Is there a good way to test the atomicity of code? I could fire up
multiple threads and let them simultaneously hammer away at a shared
hash, but I'm not sure this would be a good reproducible test case.

- Can anyone think of a way to allow the three Set methods (entrySet,
keySet, values) to return modifiable values? That is, if you remove an
item from them, they atomically affect the original BiMap.

Thanks for any pointers,

Norman

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

ConcurrentBiMap.java (6K) Download Attachment
ConcurrentBiMapTests.java (8K) Download Attachment

Re: [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?

2009-11-20T11:45:42Z

Does this only happen with Java or does it happen with other processes as well?

Try running multiple copies of some other long lived process and see if they are all running on a single processor. If they are, you are running into an issue with the OS (most likely a configuration limiting your user to a single processor).

samuel

On Fri, Nov 20, 2009 at 11:35 AM, Safe P. <z8sbk@...> wrote:

David, thank you for your answer.

The problem is exactly this:

when I run java -cp . MyProcess & java -cp .MyProcess & ... in a 12-core machine that runs HP-UX, all processes are assign to one processor.

That means that an instance must wait until the end of the previous instance to start. I want to run all instances in parallel, using all 12 processors. Is this possibly? Maybe using ThreadPoolExecutor to execute each instance of this "java -cp .."?

Thank you very much in advance!

--- El jue 19-nov-09, David Holmes <davidcholmes@...> escribió:

De: David Holmes <davidcholmes@...>
Asunto: RE: [concurrency-interest] [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?
Para: "Safe P." <z8sbk@...>, concurrency-interest@...
Fecha: jueves, 19 de noviembre de 2009, 9:45 pm

Matias,

I'm not really understanding your problem/issue, but most systems have some notion of processing domains that let you allocate resources (memory and CPU) to a domain and then run specific processes in specific domains. On Solaris this is done with processor sets, while on Linux there are CPU-sets. I don't know what HP-UX has.

There are no Java API's to control thread or process affinity (other than by exec'ing OS utilities to do it, or calling your own native code routines.

Normally, absent any domains, all processes (and all their threads) can run on any available processor/core.

HTH.

David Holmes

-----Original Message-----
From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...]On Behalf Of Safe P.
Sent: Friday, 20 November 2009 9:35 AM
To: concurrency-interest@...
Subject: [concurrency-interest] [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?

Hi,
I'm very new to concurrent programming and I couldn't find anywhere if this is an issue or just a limitation.

I'm running several instances of a java process like "process.sh & process.sh & process.sh ..." in an HP-UX that runs over a 12-core machine.

When I use sar, top, and other utilities I can see that HP-UX is using just 1 core. It doesn't manage to assign one processor per process.

Can I get this using ThreadPoolExecutor (like one System.Runtime.exec() per thread)?

Unfortunately, this machine is a production server so I can't get access to it in order to do some test and verify that, and of course, if this make a significant time improvement.

Thank you very much in advanced.
--Matias

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?

2009-11-20T11:45:05Z

He's saying it's probably a config issue with your OS, not a Java problem.

- DML

On 11/20/2009 01:35 PM, Safe P. wrote:

> David, thank you for your answer.
>
> The problem is exactly this:
>
> when I run java -cp . MyProcess & java -cp .MyProcess & ... in a 12-core
> machine that runs HP-UX, all processes are assign to one processor.
>
> That means that an instance must wait until the end of the previous
> instance to start. I want to run all instances in parallel, using all 12
> processors. Is this possibly? Maybe using ThreadPoolExecutor to execute
> each instance of this "java -cp .."?
>
> Thank you very much in advance!
>
>
> --- El *jue 19-nov-09, David Holmes /<davidcholmes@...>/* escribió:
>
>
> De: David Holmes <davidcholmes@...>
> Asunto: RE: [concurrency-interest] [CPU Affinity] ThreadPoolExecutor
> to improve"O.S Scheduler" ?
> Para: "Safe P." <z8sbk@...>, concurrency-interest@...
> Fecha: jueves, 19 de noviembre de 2009, 9:45 pm
>
> Matias,
> I'm not really understanding your problem/issue, but most systems
> have some notion of processing domains that let you allocate
> resources (memory and CPU) to a domain and then run specific
> processes in specific domains. On Solaris this is done with
> processor sets, while on Linux there are CPU-sets. I don't know what
> HP-UX has.
> There are no Java API's to control thread or process affinity (other
> than by exec'ing OS utilities to do it, or calling your own native
> code routines.
> Normally, absent any domains, all processes (and all their threads)
> can run on any available processor/core.
> HTH.
> David Holmes
>
> -----Original Message-----
> *From:* concurrency-interest-bounces@...
> [mailto:concurrency-interest-bounces@...]*On Behalf Of
> *Safe P.
> *Sent:* Friday, 20 November 2009 9:35 AM
> *To:* concurrency-interest@...
> *Subject:* [concurrency-interest] [CPU Affinity]
> ThreadPoolExecutor to improve"O.S Scheduler" ?
>
> Hi,
> I'm very new to concurrent programming and I couldn't find
> anywhere if this is an issue or just a limitation.
> I'm running several instances of a java process like "process.sh
> & process.sh & process.sh ..." in an HP-UX that runs over a
> 12-core machine.
>
> When I use sar, top, and other utilities I can see that HP-UX is
> using just 1 core. It doesn't manage to assign one processor per
> process.
> Can I get this using ThreadPoolExecutor (like one
> System.Runtime.exec() per thread)?
> Unfortunately, this machine is a production server so I can't
> get access to it in order to do some test and verify that, and
> of course, if this make a significant time improvement.
>
> Thank you very much in advanced.
> --Matias
>
>
> ------------------------------------------------------------------------
>
> Encontra las mejores recetas con Yahoo! Cocina.
> http://ar.mujer.yahoo.com/cocina/
>
>
> ------------------------------------------------------------------------
>
> Encontra las mejores recetas con Yahoo! Cocina.
> http://ar.mujer.yahoo.com/cocina/
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?

2009-11-20T11:35:07Z

David, thank you for your answer.

The problem is exactly this:

when I run java -cp . MyProcess & java -cp .MyProcess & ... in a 12-core machine that runs HP-UX, all processes are assign to one processor.

That means that an instance must wait until the end of the previous instance to start. I want to run all instances in parallel, using all 12 processors. Is this possibly? Maybe using ThreadPoolExecutor to execute each instance of this "java -cp .."?

Thank you very much in advance!

--- El jue 19-nov-09, David Holmes <davidcholmes@...> escribió:

De: David Holmes <davidcholmes@...>
Asunto: RE: [concurrency-interest] [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?
Para: "Safe P." <z8sbk@...>, concurrency-interest@...
Fecha: jueves, 19 de noviembre de 2009, 9:45 pm

Matias,

I'm not really understanding your problem/issue, but most systems have some notion of processing domains that let you allocate resources (memory and CPU) to a domain and then run specific processes in specific domains. On Solaris this is done with processor sets, while on Linux there are CPU-sets. I don't know what HP-UX has.

There are no Java API's to control thread or process affinity (other than by exec'ing OS utilities to do it, or calling your own native code routines.

Normally, absent any domains, all processes (and all their threads) can run on any available processor/core.

HTH.

David Holmes

-----Original Message-----
From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...]On Behalf Of Safe P.
Sent: Friday, 20 November 2009 9:35 AM
To: concurrency-interest@...
Subject: [concurrency-interest] [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?

Hi,
I'm very new to concurrent programming and I couldn't find anywhere if this is an issue or just a limitation.

I'm running several instances of a java process like "process.sh & process.sh & process.sh ..." in an HP-UX that runs over a 12-core machine.

When I use sar, top, and other utilities I can see that HP-UX is using just 1 core. It doesn't manage to assign one processor per process.

Can I get this using ThreadPoolExecutor (like one System.Runtime.exec() per thread)?

Unfortunately, this machine is a production server so I can't get access to it in order to do some test and verify that, and of course, if this make a significant time improvement.

Thank you very much in advanced.
--Matias

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: park and unpark low-level details

2009-11-20T10:41:48Z

Dave Dice wrote:

> On 2009-11-20, at 12:46 PM, Andrew Haley wrote:
>
>> Something I've been wondering about.
>>
>> In "The java.util.concurrent Synchronizer Framework" Doug writes:
>>
>> << This simple mechanism is similar to those used, at some level, in
>> the Solaris-9 thread library [11], in WIN32 "consumable events", and
>> in the Linux NPTL thread library, and so maps efficiently to each of
>> these on the most common platforms Java runs on. (However, the
>> current Sun Hotspot JVM reference implementation on Solaris and Linux
>> actually uses a pthread condvar in order to fit into the existing
>> runtime design.) >>
>>
>> What do you man by this? I guess there's a nice way to map park and
>> unpark onto low-level NPTL primitives (futexes, perhaps?) Did you
>> have a sketch of a design for that?
>

> We preferred to use more standardized interfaces. I experimented
> with using futexes instead of the usual condvar-mutex-flag tuple but
> it wasn't particularly better.

I'm not surprised. I did some profiling, and even with quite heavily
contended locks the time spent in park and unpark is often down in
the noise. Amazing, really. :-)

> (Likewise, Solaris has low-level __lwp_park and __lwp_park
> interfaces that also work nicely, but they aren't officially exposed
> and subject change from release to release).

> One of the more interesting approaches is to use pipe pairs. (I
> left comments in the code that explain this in more detail).
> Perversely, this is one of the best implementations for Solaris and
> Linux, except that it can consume excessive number of file
> descriptors, which is why we're not using it.

Yes, I read that. I guess you'd use open() with O_NONBLOCK and
select() with a timeout for timed waits. This does have a really nice
feel to it; it's a shame file descriptors turn out to be such a scarce
resource.

>> It probably doesn't much matter, given that pthread mutex and conndvar
>> signal a fairly thin wrappers over futexes, but unparking a blocked
>> thread requires three pthread_ calls:
>>
>> int status = pthread_mutex_lock(_mutex);
>>
>> AnyWaiters = _nParked ;
>>
>> status = pthread_mutex_unlock(_mutex);
>>
>> if (AnyWaiters != 0) {
>> status = pthread_cond_signal(_cond);
>> }
>

> You're apparently looking at the PlatformEvent:: implementation and
> not Parker::. PlatformEvent:: is used by the built-in
> synchronization primitives and native C++ JVM internal mutexes and
> monitors, whereas Parker:: is infrastructure used by LockSupport.
> They're similar -- and someday should be reconciled -- but have
> slightly different semantics.

Ah, my mistake. However, exactly the same is true of Parker::park:

status = pthread_mutex_lock(_mutex);
s = _counter;
_counter = 1;
if (s < 1) {
status = pthread_mutex_unlock(_mutex);
status = pthread_cond_signal (_cond) ;
}
} else {
pthread_mutex_unlock(_mutex);
}

I suppose this question is more to do with the fact that it doesn't
quite feel right (to me) to be using all these pthread calls in the
lowest-level Java primitives, rather than anything real to do with
performance.

Thanks,
Andrew.

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

park and unpark low-level details

2009-11-20T09:46:52Z

Something I've been wondering about.

In "The java.util.concurrent Synchronizer Framework" Doug writes:

<< This simple mechanism is similar to those used, at some level, in
the Solaris-9 thread library [11], in WIN32 "consumable events", and
in the Linux NPTL thread library, and so maps efficiently to each of
these on the most common platforms Java runs on. (However, the
current Sun Hotspot JVM reference implementation on Solaris and Linux
actually uses a pthread condvar in order to fit into the existing
runtime design.) >>

What do you man by this? I guess there's a nice way to map park and
unpark onto low-level NPTL primitives (futexes, perhaps?) Did you
have a sketch of a design for that?

It probably doesn't much matter, given that pthread mutex and conndvar
signal a fairly thin wrappers over futexes, but unparking a blocked
thread requires three pthread_ calls:

int status = pthread_mutex_lock(_mutex);

AnyWaiters = _nParked ;

status = pthread_mutex_unlock(_mutex);

if (AnyWaiters != 0) {
status = pthread_cond_signal(_cond);
}

(I realize that the mutex is necessary to prevent a race when signalling
a thread that's parking. I just wondered if you'd had another design in
mind.)

Thanks,
Andrew.
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?

2009-11-19T15:45:22Z

Matias,

I'm not really understanding your problem/issue, but most systems have some notion of processing domains that let you allocate resources (memory and CPU) to a domain and then run specific processes in specific domains. On Solaris this is done with processor sets, while on Linux there are CPU-sets. I don't know what HP-UX has.

There are no Java API's to control thread or process affinity (other than by exec'ing OS utilities to do it, or calling your own native code routines.

Normally, absent any domains, all processes (and all their threads) can run on any available processor/core.

HTH.

David Holmes

-----Original Message-----
From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...]On Behalf Of Safe P.
Sent: Friday, 20 November 2009 9:35 AM
To: concurrency-interest@...
Subject: [concurrency-interest] [CPU Affinity] ThreadPoolExecutor to improve"O.S Scheduler" ?

Hi,
I'm very new to concurrent programming and I couldn't find anywhere if this is an issue or just a limitation.

I'm running several instances of a java process like "process.sh & process.sh & process.sh ..." in an HP-UX that runs over a 12-core machine.

When I use sar, top, and other utilities I can see that HP-UX is using just 1 core. It doesn't manage to assign one processor per process.

Can I get this using ThreadPoolExecutor (like one System.Runtime.exec() per thread)?

Unfortunately, this machine is a production server so I can't get access to it in order to do some test and verify that, and of course, if this make a significant time improvement.

Thank you very much in advanced.
--Matias

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[CPU Affinity] ThreadPoolExecutor to improve "O.S Scheduler" ?

2009-11-19T15:34:32Z

Hi,
I'm very new to concurrent programming and I couldn't find anywhere if this is an issue or just a limitation.

I'm running several instances of a java process like "process.sh & process.sh & process.sh ..." in an HP-UX that runs over a 12-core machine.

When I use sar, top, and other utilities I can see that HP-UX is using just 1 core. It doesn't manage to assign one processor per process.

Can I get this using ThreadPoolExecutor (like one System.Runtime.exec() per thread)?

Unfortunately, this machine is a production server so I can't get access to it in order to do some test and verify that, and of course, if this make a significant time improvement.

Thank you very much in advanced.
--Matias

Re: Conja-- an accidental jsr166y alternative

2009-11-19T00:19:16Z

One main thing obviously. Sorry about the misinformation.

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest