Nabble - JSR166 Concurrency

Re: Project FishFarm; making a ForkJoinPool distributeable

2008-09-06T11:43:01Z

Sorry for the long delay replying to this!

Michael Bien wrote:
> -made ForkJoinTask Serializeable

We can't mandate that all ForkJoinTasks are serializable.
In a non-JDK release maybe we could, because then we
could just tell people creating subclasses (which is the main
way you use FJ) to ignore the serializablility
if they don't need it, because nothing actually relies on it.
An alternative would be to introduce SerializableForkJoinTask,
but then we'd need the basic exec internals fleshed out for
the various main flavors (SerializableRecursiveAction etc)
because we don't/can't allow people to implement these themselves.

Further, all you really want here is to
ensure that arguments and results are serializable. Sadly
you can't write this as a conjunctive type like:
void foo([ForkJoinTask & Serializable] task)
So my best suggestion, sadly enough, is to rely on
dynamic typing, as in:
void foo(ForkJoinTask task) {
if (!(task implements Serializable)) throw...

Which would then entail javadoc @param specs etc that
spell out the otherwise unstated type requirements.

(Perhaps someone has already created an annotation tag
along these lines?)

How bad would that be?

> -added popQuedTask() to ForkJoinPool which returns a not-yet executed
> task and removes it from the pool (i am pretty sure this will not work
> under all conditions)

You mean a submission to a pool, right?
That is now possible via ForkJoinWorkerThread.pollSubmission.
It seems somewhat dangerous to expose the ForkJoinPool version
so that non-FJ code can remove tasks, but maybe there is
a good argument for it?

> -added getTask() to Submission

The Submission class is not even public, so this
by itself wouldn't do much good. For plumbing-level
manipulation though, perhaps you could use privileged
reflection to directly access the task field?

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

Re: forkjoin updates

2008-09-06T10:37:50Z

The BasicAsyncAction class doesn't appear to be in CVS.

Doug Lea wrote:
> An updated jsr166y package is available. The changes
> are mainly focussed on internal reducing overhead and improving
> scalability. There are some visible changes though:
>
> * Phasers now support tiering -- you can create trees
> of them to reduce contention. (Initial plans were
> to do this internally/adaptively, but exposing
> it leaving it up to users works out better.)
>
> * AsyncAction is now a base class for (existing) class
> LinkedAsyncAction, along with new classes BasicAsyncAction
> (a minimal implementation) and BinraryAsyncAction. Async
> actions take some attitude adjustment to get used to, but
> are more flexible than Recursive{Action,Task}.
>
> * CyclicAction has disappeared, probably to be replaced
> by better support for mixing long-lived looping threads
> running in ExecutorServices with data-parallel tasks running
> in ForkJoinPools. (Which is possible even now, but not
> always easy to set up.) Similarly for Phaser integration.
>
> * A few small utility methods that probably no
> one has used have gone away, and a few better
> documented ones introduced.
>
> Some of the main streamlining improvements rely on
> Java6 features. (It also runs of course on
> early-access versions of openjdk/jdk7.)
> There is no longer even internal guidance on
> how to adapt for Java5. If you must run on Java5, you
> probably want to keep using older snaphots.
>
> Comments welcome as always. Things are in their usual places:
> API specs:
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/
> jar file:
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166y.jar
> Browsable CVS sources:
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/
>
> -Doug
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>

Get more out of the Web. Learn 10 hidden secrets of Windows Live. Learn Now
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

forkjoin updates

2008-09-06T07:08:31Z

An updated jsr166y package is available. The changes
are mainly focussed on internal reducing overhead and improving
scalability. There are some visible changes though:

* Phasers now support tiering -- you can create trees
of them to reduce contention. (Initial plans were
to do this internally/adaptively, but exposing
it leaving it up to users works out better.)

* AsyncAction is now a base class for (existing) class
LinkedAsyncAction, along with new classes BasicAsyncAction
(a minimal implementation) and BinraryAsyncAction. Async
actions take some attitude adjustment to get used to, but
are more flexible than Recursive{Action,Task}.

* CyclicAction has disappeared, probably to be replaced
by better support for mixing long-lived looping threads
running in ExecutorServices with data-parallel tasks running
in ForkJoinPools. (Which is possible even now, but not
always easy to set up.) Similarly for Phaser integration.

* A few small utility methods that probably no
one has used have gone away, and a few better
documented ones introduced.

Some of the main streamlining improvements rely on
Java6 features. (It also runs of course on
early-access versions of openjdk/jdk7.)
There is no longer even internal guidance on
how to adapt for Java5. If you must run on Java5, you
probably want to keep using older snaphots.

Comments welcome as always. Things are in their usual places:
API specs:
http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/
jar file:
http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166y.jar
Browsable CVS sources:
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/

-Doug

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

tool for converting sequential code to use j.u.c.

2008-09-02T19:58:15Z

Hello j.u.c. enthusiasts,

We've been working on a tool for reengineering Java sequential code for
concurrency by using j.u.c. utilities.

We are announcing the first release of our tool, Concurrencer. It converts
int fields to AtomicIntegers, and HashMap fields to ConcurrentHashMap.
Concurrencer is implemented as an extension to Eclipse's refactoring engine.
We've tried it on a few open-source projects and we found that (i) Concurrencer
saves the programmer from changing many lines of code,
(ii) is not error-prone like manual conversion, and (iii) is less
omission-prone then
the human.

We would love to get your feedback on the tool. Please use the tool and let us
know if it is useful. We are looking for constructive criticism on how we can
improve it.

Please visit the webpage below for instructions on how to get the tool. The
webpage also contains a white paper (currently under review to a workshop)
describing the features of Concurrencer. Due to lack of space, the paper
does not contain many details like the data flow analysis for
ConvertToConcurrentHashMap. It turns out that converting usages of put() to
putIfAbsent() is not trivial, and has very interesting cases. Please try some
variations yourself and let us know.

Here comes the webpage:
http://people.csail.mit.edu/dannydig/CR/

Currently we are implementing another transformation. It converts a recursive
divide-and-conquer method into one which uses the FJTask framework and the
RecursiveAction. We've tried it on a few textbook algorithms (e.g., fibonacci,
quicksort, mergesort, matrix multiplication). We have not released yet this
refactoring since it is not fully finished. Do you have some examples of real
code which was converted to use RecursiveAction (other than the examples
coming with forkjoin Javadoc)?

looking forward to receiving your feedback,
Danny

--
Danny Dig's homepage: http://netfiles.uiuc.edu/dig/www

Motto: "Success is not for the chosen few but for the few who choose"
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: backport of java.util.concurrent: Bug in Arrays.deepEquals()

2008-09-02T00:39:42Z

+ concurrency-interest

Thanks! I'll look into it.

On Fri, Aug 29, 2008 at 11:30 AM, Philipp Buluschek
<philipp@...> wrote:

> Dear Sir,
> I am using your backport to the java.util.concurrent. (version 3.1 for java
> 1.2)
>
> In the package you distribute, there is also a backport for the
> java.util.Arrays class, which is very handy. Unfortunately, I think that the
> implementation of the deepEquals() method contains a bug. The following test
> case should return true, while in the present implementation it returns
> false. The present implementation in Sun's SDK 6.0 is correct in this
> regard. Maybe you could update the packages to the implementation from Sun?
>
> Thank you again for your work in backporting the j.u.concurrent classes.
> Best regards
> Philipp Buluschek
>
> --- test case ---
> import edu.emory.mathcs.backport.java.util.Arrays;
> public class ArraysEqualsTest {
> public static void main(String[] args) {
> float[][] f1 = {{1,2},{3.1415f, 2.7183f}};
> float[][] f2 = {{1,2},{3.1415f, 2.7183f}};
> System.out.println(Arrays.deepEquals(f1, f2)); // should return
> true, but returns false
> }
> }
>
> --
> ________________________________________
>
> Philipp Buluschek, Dr-Ing. Dipl. EPFL
> Software Design & Implementation
> Schellingstr. 16
> D-80799 München, Germany
> Phone: +49 89 2875 5533
> Mobile: +49 157 7580 8218
> E-mail: philipp@...
> ________________________________________
>
>

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

Re: Learning Java.util.concurrent

2008-08-28T04:57:54Z

The fork join stuff in Java is not yet final, and not described in any
books (implementation still is subject to change).

On the IBM site there are some articles about it written by Brian Goetz:
http://www.ibm.com/developerworks/java/library/j-jtp11137.html
http://www.ibm.com/developerworks/java/library/j-jtp03048.html

And there also is a paper about the fork join framework you could study:
http://gee.cs.oswego.edu/dl/papers/fj.pdf

But I don't know how much it is in sync with the current
implementation.But it is very informative anyway.

You could also check out the Intel thread building blocks:
http://www.amazon.com/Intel-Threading-Building-Blocks-Parallelism/dp/0596514808/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1219923968&sr=8-1
There is a lot of overlap in both libraries and it never hurts to look
at fork join problems using different glasses.

For a more general approach you could also check out:
http://www.amazon.com/Patterns-Parallel-Programming-Software/dp/0321228111/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1219924058&sr=1-1
It describes the fork join pattern and a lot of other patterns related
to parallel programming.

And for concurrency in Java the following books are my favorites:

http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1219924258&sr=1-1
Very practical and describes the stuff introduced in Java 5.

http://www.amazon.com/Concurrent-Programming-Java-TM-Principles/dp/0201310090/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1219924428&sr=1-1
A classic book. Even though it is almost 10 years old, it is still
very valuable.

Both books complement each other.. one is more practical.. and the
other is more theoretical. And to do concurrency control well, you
need to be educated in both areas.

On Thu, Aug 28, 2008 at 8:54 AM, Ganesh Bikshandi <gbikshan@...> wrote:

>
> Dear Members,
>
> I want to learn about java.util.concurrent. Which is the best source? If
> there is a text book, that will be of great use. Especially, I want to
> lear about the fork-join stuff.
>
> Best Regards,
> Ganesh
>
> _______________________________________________
> 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

Learning Java.util.concurrent

2008-08-27T23:54:38Z

Dear Members,

I want to learn about java.util.concurrent. Which is the best source? If
there is a text book, that will be of great use. Especially, I want to
lear about the fork-join stuff.

Best Regards,
Ganesh

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

Re: FJ usage question: Mutable procedures

2008-08-26T07:53:38Z

Thanks, a raw RecursiveAction does the trick for me for now.

Note: there are two bugs in the examples http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/jsr166y/forkjoin/RecursiveAction.html

In the sumOfSquares example, the compute() method iterates while i < h :

for (int i = l; i < h; ++i) // perform leftmost base step
sum += array[i] * array[i];

Thus, the constructor call

Applyer a = new Applyer(array, 0, n-1, seqSize, null);

should not subtract one from n:

Applyer a = new Applyer(array, 0, n, seqSize, null);

Also, in Applyer in the javadoc

int result;

should be

double result;

> Date: Tue, 26 Aug 2008 08:59:59 -0400
> From: Doug Lea <dl@...>
> CC: <concurrency-interest@...>
>
> David J. Biesack wrote:
> > ParallelDoubleArray has a summary() method; but it's not implemented in
> > terms of the public apply/Ops.DoubleProcedure API of
> > ParallelDoubleArray. I'd like to make that more general and define a
> > Ops.DoubleProcedure to compute extended summary statistics, or perform
> > other operations which require updating state within the ops/procedures.
>
> This is one of the basic tradeoffs made in ParallelArray:
> It knows how to translate fixed families of array operations
> into underlying fork/join processing. While we can and should
> keep adding to this family (as in supporting indexed procedures),
> there will always only be a finite set of functional/procedural
> forms that it understands.
>
> When you need to go beyond them, the best recourse is to
> step into the fun world of direct fork/join programming.
> Often, it is fairly straightforward, as in the examples
> (with more to come) in the RecursiveAction etc javadoc.
> ParallelArray includes a bunch of tweaks that improve
> performance over the basic templates (which it needs
> in part because it must act without any programmer
> supplied granularity information). The next update
> (real soon now) will include documented, exposed
> methods and classes that allow others to use them too,
> but most of these can be ignored in everyday programming.
>
> -Doug
>

--
David J. Biesack SAS Institute Inc.
(919) 531-7771 SAS Campus Drive
http://www.sas.com Cary, NC 27513
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: FJ usage question: Mutable procedures

2008-08-26T05:59:59Z

David J. Biesack wrote:
> ParallelDoubleArray has a summary() method; but it's not implemented in
> terms of the public apply/Ops.DoubleProcedure API of
> ParallelDoubleArray. I'd like to make that more general and define a
> Ops.DoubleProcedure to compute extended summary statistics, or perform
> other operations which require updating state within the ops/procedures.

This is one of the basic tradeoffs made in ParallelArray:
It knows how to translate fixed families of array operations
into underlying fork/join processing. While we can and should
keep adding to this family (as in supporting indexed procedures),
there will always only be a finite set of functional/procedural
forms that it understands.

When you need to go beyond them, the best recourse is to
step into the fun world of direct fork/join programming.
Often, it is fairly straightforward, as in the examples
(with more to come) in the RecursiveAction etc javadoc.
ParallelArray includes a bunch of tweaks that improve
performance over the basic templates (which it needs
in part because it must act without any programmer
supplied granularity information). The next update
(real soon now) will include documented, exposed
methods and classes that allow others to use them too,
but most of these can be ignored in everyday programming.

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

FJ usage question: Mutable procedures

2008-08-25T12:59:36Z

ParallelDoubleArray has a summary() method; but it's not implemented in
terms of the public apply/Ops.DoubleProcedure API of
ParallelDoubleArray. I'd like to make that more general and define a
Ops.DoubleProcedure to compute extended summary statistics, or perform
other operations which require updating state within the ops/procedures.
As noted earlier, there is no IntAndDoubleProcedure, so I'm using a
mutable Ops.IntAndDoubleToDouble instead

Naturally, I must add a lock around the mutating portions of the class

@Override
public double op(final int index, final double a) {
// System.out.println(a);
if (!Double.isNaN(a)) {
synchronized (this) {
sum += a;
sumOfSquares += (a * a);
n++;
if (a > max) {
max = a;
maxIndex = index;
}
if (a < min) {
min = a;
minIndex = index;
}
}

}
return a;
}

However, the PAS.FJDStats does not use synchronization but rather
creates new instances during the divide/conquer algorithms, and thus no
race conditions.

However, I don't see where this divide/conquer approach is part of the
public ParallelArray API; PAS and its kin are not public.

I would like to be able to do the divide/conquer for general purpose
mutable procedures/mappings. Is this possible? Another more simplistic
option would be to use ex.getParallelismLevel() and be able to create an
array of procedures/mappers, each of which the framework guarantees
safe, non-blocking execution

Ops.DoubleProcedure procedures[] = new MyProcedure[ex.getParallelismLevel()];
// initialize
parallelArray.apply(procedures);

after which I can run a reducer over that array to combine their
intermediate results.

Or, are there better ways to achieve these goals?

--
David J. Biesack SAS Institute Inc.
(919) 531-7771 SAS Campus Drive
http://www.sas.com Cary, NC 27513
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Cost of Inserting bytecodes around monitorenter and monitorexit

2008-08-20T10:21:20Z

(Sorry this is a long message.)

Hi everyone. I have a question/problem that is a bit off topic, but I
need the advice of those who understand synchronization and the JVM
intimately. I am manipulating Java classfiles (using ASM) as part of a
profiling project. I was trying to understand the overhead created by
the inserted bytecodes, and I was surprised to see how much overhead I
have when I instrument around monitorenter and monitorexit operations.
Primarily my inserted bytecodes set up method calls to a data collection
class. I insert a method call before and after monitorenter and after
moniterexit. In this case, I have subsituted a data collection class
that has empty methods.

I am concerned because on my test case, the unintrumented program runs
in under 4 minutes. If I instrument only monitorenter and monitorexit
bytecodes, the program takes over 20 minutes to run. Before you tell me
that it is the inserted method calls that cause the problem, let me say
this: If I instead instrument only method calls which also causes 3
additional methods to be called for each original method call, the
entire
program runs in around 5 minutes. So I think there is something very
strange going on related to synchronization.

To be more specific, I have created a simpler test class. This class
doesn't do anything useful. It is just designed to exercise a bunch of
synchronized blocks. All the important stuff is in the Shared class.

public class Main {
public static void main(final String[] args) {
System.out.println("Main");

final Shared s = new Shared();
final Thread threadA = new Thread(new A(s));
final Thread threadB = new Thread(new B(s));

final long startTime = System.currentTimeMillis();
threadA.start();
threadB.start();

while (threadA.isAlive() && threadB.isAlive()) {
try {
threadA.join();
threadB.join();
} catch (final InterruptedException e) {
// won't happen
}
}

final long endTime = System.currentTimeMillis();
final long time = endTime - startTime;
System.out.println("Done in " + time + "ms (" + ((time/1000.0)/
60.0) + " minutes)");
}
}

class A implements Runnable {
private static final int START = 2500000;
private Shared s;

public A(final Shared s) {
this.s = s;
s.forB(START);
}

public void run() {
while (true) {
try {
final int v = s.fromB();
if (v <= 0) {
s.forB(v);
break;
}
s.forB(v+1);
} catch(final InterruptedException e) {
// won't happen
}
}
}
}

class B implements Runnable {
private Shared s;

public B(final Shared s) {
this.s = s;
}

public void run() {
while (true) {
try {
final int v = s.fromA();
if (v <= 0) {
s.forA(v);
break;
}
s.forA(v-2);
} catch (final InterruptedException e) {
// won't happen
}
}
}
}

class Shared {
private boolean hasForB = false;
private int fromAforB;

private boolean hasForA = false;
private int fromBforA;

public void forB(final int v) {
forB_impl(this, v);
}

private void forB_impl(final Object lock, final int v) {
synchronized (lock) {
fromAforB = v;
hasForB = true;
lock.notifyAll();
}
}

public void forA(final int v) {
forA_impl(this, v);
}

private void forA_impl(final Object lock, final int v) {
synchronized (lock) {
fromBforA = v;
hasForA = true;
lock.notifyAll();
}
}

public int fromB() throws InterruptedException {
return fromB_impl(this);
}

private int fromB_impl(final Object lock) throws
InterruptedException {
synchronized (lock) {
while (!hasForA) {
lock.wait();
}
hasForA = false;
return fromBforA;
}
}

public int fromA() throws InterruptedException {
return fromA_impl(this);
}

private int fromA_impl(final Object lock) throws
InterruptedException {
synchronized (lock) {
while (!hasForB) {
lock.wait();
}
hasForB = false;
return fromAforB;
}
}
}

The Shared class is using an extra layer of delegation because I was
trying to prevent the Java and JIT compilers from taking advantage of
the fact that the lock is known to be the receiver; this is important
below.

When I run this class normally on my Intel Core 2 Duo iMac, under Java
5, it takes about 33 seconds. When I run with instrumentation added
around each monitorenter and monitorexit bytecode, it runs in about 39
seconds. I have similar (but slower) results on an older Intel Dell
Laptop running Java 6.

Now, here is where it gets very strange. I created a version of the
Shared class that approximates very closely the instrumentation that is
being added in the bytecode:

class Shared {
private boolean hasForB = false;
private int fromAforB;

private boolean hasForA = false;
private int fromBforA;

public void forB(final int v) {
forB_impl(this, v);
}

private void forB_impl(final Object lock, final int v) {
try {
Store.beforeStart(lock, lock == this, lock == Shared.class,
Shared.class, 1);
synchronized (lock) {
Store.afterStart(lock, Shared.class, 1);
fromAforB = v;
hasForB = true;
lock.notifyAll();
}
} finally {
Store.afterEnd(this, Shared.class, 10);
}
}

public void forA(final int v) {
forA_impl(this, v);
}

private void forA_impl(final Object lock, final int v) {
try {
Store.beforeStart(lock, lock == this, lock == Shared.class,
Shared.class, 1);
synchronized (lock) {
Store.afterStart(lock, Shared.class, 1);
fromBforA = v;
hasForA = true;
lock.notifyAll();
}
} finally {
Store.afterEnd(this, Shared.class, 10);
}
}

public int fromB() throws InterruptedException {
return fromB_impl(this);
}

private int fromB_impl(final Object lock) throws
InterruptedException {
try {
Store.beforeStart(lock, lock == this, lock == Shared.class,
Shared.class, 1);
synchronized (lock) {
Store.afterStart(lock, Shared.class, 1);
while (!hasForA) {
lock.wait();
}
hasForA = false;
return fromBforA;
}
} finally {
Store.afterEnd(this, Shared.class, 10);
}
}

public int fromA() throws InterruptedException {
return fromA_impl(this);
}

private int fromA_impl(final Object lock) throws
InterruptedException {
try {
Store.beforeStart(lock, lock == this, lock == Shared.class,
Shared.class, 1);
synchronized (lock) {
Store.afterStart(lock, Shared.class, 1);
while (!hasForB) {
lock.wait();
}
hasForB = false;
return fromAforB;
}
} finally {
Store.afterEnd(this, Shared.class, 10);
}
}
}

class Store {
public static void beforeStart(
final Object o, final boolean a, final boolean b, Class c, int
l) {}
public static void afterStart(final Object o, Class c, int l) {}
public static void afterEnd(final Object o, Class c, int l) {}
}

This is where I want to avoid taking advantage of the fact that the lock
is the receiver. Obviously, this isn't going to be exactly the same as
the instrumented bytecode, because the bytecode manipulator doens't know
what operations preceeded the monitorenter or monitorexit operations and
has to do some possibly redundant swap and dup stack manipulations. But
it's pretty close. When I run this version, it completes in about 33
seconds. Actually, sometimes it seems to be slightly faster than the
original, running in 32 seconds.

This doesn't make any sense to me. Other instrumentation that I insert
uses swap and dup, and is not heavily penalized. I actually rewrote the
transformation to use local variables to avoid the use of swaps and
dups, but that turned out to be even slower!

To be even more specific again, here is the bytecode for the forB_impl()
method for the different versions. (All the other methods are similar).

Original Method

// Method descriptor #29 (Ljava/lang/Object;I)V
// Stack: 2, Locals: 4
private void forB_impl(java.lang.Object lock, int v);
0 aload_1 [lock]
1 dup
2 astore_3
3 monitorenter
4 aload_0 [this]
5 iload_2 [v]
6 putfield test.Shared.fromAforB : int [31]
9 aload_0 [this]
10 iconst_1
11 putfield test.Shared.hasForB : boolean [16]
14 aload_1 [lock]
15 invokevirtual java.lang.Object.notifyAll() : void [33]
18 aload_3
19 monitorexit
20 goto 26
23 aload_3
24 monitorexit
25 athrow
26 return
Exception Table:
[pc: 4, pc: 20] -> 23 when : any
[pc: 23, pc: 25] -> 23 when : any
Line numbers:
[pc: 0, line: 15]
[pc: 4, line: 16]
[pc: 9, line: 17]
[pc: 14, line: 18]
[pc: 18, line: 15]
[pc: 26, line: 20]
Local variable table:
[pc: 0, pc: 27] local: this index: 0 type: test.Shared
[pc: 0, pc: 27] local: lock index: 1 type: java.lang.Object
[pc: 0, pc: 27] local: v index: 2 type: int

Pseudo-Instrumented Method

// Method descriptor #29 (Ljava/lang/Object;I)V
// Stack: 5, Locals: 5
private void forB_impl(java.lang.Object lock, int v);
0 aload_1 [lock]
1 aload_1 [lock]
2 aload_0 [this]
3 if_acmpne 10
6 iconst_1
7 goto 11
10 iconst_0
11 aload_1 [lock]
12 ldc <Class testInst.Shared> [1]
14 if_acmpne 21
17 iconst_1
18 goto 22
21 iconst_0
22 ldc <Class testInst.Shared> [1]
24 iconst_1
25 invokestatic testInst.Store.beforeStart(java.lang.Object,
boolean, boolean, java.lang.Class, int) : void [31]
28 aload_1 [lock]
29 dup
30 astore_3
31 monitorenter
32 aload_1 [lock]
33 ldc <Class testInst.Shared> [1]
35 iconst_1
36 invokestatic testInst.Store.afterStart(java.lang.Object,
java.lang.Class, int) : void [37]
39 aload_0 [this]
40 iload_2 [v]
41 putfield testInst.Shared.fromAforB : int [41]
44 aload_0 [this]
45 iconst_1
46 putfield testInst.Shared.hasForB : boolean [16]
49 aload_1 [lock]
50 invokevirtual java.lang.Object.notifyAll() : void [43]
53 aload_3
54 monitorexit
55 goto 74
58 aload_3
59 monitorexit
60 athrow
61 astore 4
63 aload_0 [this]
64 ldc <Class testInst.Shared> [1]
66 bipush 10
68 invokestatic testInst.Store.afterEnd(java.lang.Object,
java.lang.Class, int) : void [46]
71 aload 4
73 athrow
74 aload_0 [this]
75 ldc <Class testInst.Shared> [1]
77 bipush 10
79 invokestatic testInst.Store.afterEnd(java.lang.Object,
java.lang.Class, int) : void [46]
82 return
Exception Table:
[pc: 32, pc: 55] -> 58 when : any
[pc: 58, pc: 60] -> 58 when : any
[pc: 0, pc: 61] -> 61 when : any
Line numbers:
[pc: 0, line: 16]
[pc: 28, line: 17]
[pc: 32, line: 18]
[pc: 39, line: 19]
[pc: 44, line: 20]
[pc: 49, line: 21]
[pc: 53, line: 17]
[pc: 61, line: 23]
[pc: 63, line: 24]
[pc: 71, line: 25]
[pc: 74, line: 24]
[pc: 82, line: 26]
Local variable table:
[pc: 0, pc: 83] local: this index: 0 type: testInst.Shared
[pc: 0, pc: 83] local: lock index: 1 type: java.lang.Object
[pc: 0, pc: 83] local: v index: 2 type: int

Instrumented Method

// Method descriptor #29 (Ljava/lang/Object;I)V
// Stack: 9, Locals: 4
private void forB_impl(java.lang.Object lock, int v);
0 aload_1 [lock]
1 dup
2 astore_3
3 dup
4 dup
5 ldc <Class test.Shared> [1]
7 dup_x2
8 swap
9 dup_x1
10 dup
11 aload_0 [this]
12 if_acmpne 19
15 iconst_1
16 goto 20
19 iconst_0
20 dup_x2
21 pop
22 swap
23 dup_x1
24 if_acmpne 31
27 iconst_1
28 goto 32
31 iconst_0
32 swap
33 bipush 15
35 invokestatic
com.surelogic._flashlight.rewriter.test.EmptyStore.beforeIntrinsicLockAc
quisition(java.lang.Object, boolean, boolean, java.lang.Class, int) :
void [67]
38 monitorenter
39 bipush 15
41 invokestatic
com.surelogic._flashlight.rewriter.test.EmptyStore.afterIntrinsicLockAcq
uisition(java.lang.Object, java.lang.Class, int) : void [71]
44 aload_0 [this]
45 iload_2 [v]
46 putfield test.Shared.fromAforB : int [31]
49 aload_0 [this]
50 iconst_1
51 putfield test.Shared.hasForB : boolean [16]
54 aload_1 [lock]
55 invokevirtual java.lang.Object.notifyAll() : void [33]
58 aload_3
59 dup
60 monitorexit
61 ldc <Class test.Shared> [1]
63 bipush 15
65 invokestatic
com.surelogic._flashlight.rewriter.test.EmptyStore.afterIntrinsicLockRel
ease(java.lang.Object, java.lang.Class, int) : void [74]
68 goto 82
71 aload_3
72 dup
73 monitorexit
74 ldc <Class test.Shared> [1]
76 bipush 15
78 invokestatic
com.surelogic._flashlight.rewriter.test.EmptyStore.afterIntrinsicLockRel
ease(java.lang.Object, java.lang.Class, int) : void [74]
81 athrow
82 return
Exception Table:
[pc: 44, pc: 68] -> 71 when : any
[pc: 71, pc: 81] -> 71 when : any
Line numbers:
[pc: 0, line: 15]
[pc: 44, line: 16]
[pc: 49, line: 17]
[pc: 54, line: 18]
[pc: 58, line: 15]
[pc: 82, line: 20]
Local variable table:
[pc: 0, pc: 83] local: this index: 0 type: test.Shared
[pc: 0, pc: 83] local: lock index: 1 type: java.lang.Object
[pc: 0, pc: 83] local: v index: 2 type: int

In summary, I am completely stumped as to why there is a performance
difference between my bytecode-instrumented class (33 seconds) and my
Java-instrumented version (39 seconds). Is the JIT doing something that
I'm not aware of? Am I running into somekind of weird memory effect?
Can someone please shed some light on this situation?

--Aaron

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

Re: jsr166y IndexedProcedure ?

2008-08-18T12:40:55Z

David J. Biesack wrote:

> Back in January, there was some discussion of the jsr166y
> forkjoin/ParallelArray API. I had proposed the ability to pass the
> element index to the procedure via a ParallelArray.apply. Doug replied
>
> "... the lack of an indexed-procedure version of apply is
> a bug; thanks for pointing it out! This will be added."
>
> I've hit another case where this would be useful, so I'm just checking the status
> of any API changes along these lines.
>

Still on the todo list. Sorry for the long delay. I've been
revamping some of the underlying FJ mechanics to provide
better support for extended capabilities (phasers, new forms
of Async tasks etc) that also invite use of some better algorithms
underlying ParallelArray. All this needs to come together a
bit more before checkin/release. Hopefully within a week or
so, followed soon after by business-as-usual improvements like
this one.

-Doug

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

jsr166y IndexedProcedure ?

2008-08-18T11:32:20Z

Back in January, there was some discussion of the jsr166y
forkjoin/ParallelArray API. I had proposed the ability to pass the
element index to the procedure via a ParallelArray.apply. Doug replied

"... the lack of an indexed-procedure version of apply is
a bug; thanks for pointing it out! This will be added."

http://cs.oswego.edu/pipermail/concurrency-interest/2008-January/004917.html
http://cs.oswego.edu/pipermail/concurrency-interest/2008-January/004922.html

I've hit another case where this would be useful, so I'm just checking the status
of any API changes along these lines.

My use case: implementing ParallelDoubleArray.SummaryStatistics
and similar behaviors which do not mutate the ParallelDoubleArray.

I can't use summary() because I want new behavior: additional statistics
like variance and standard deviation, and pluggable value filtering;
i.e. do not include NaNs in size/sum/min/max/average.

I can't use a DoubleProcedure because I need the item index in order to
implement minIndex() and maxIndex().

I can use pda.replaceWithMappedIndex(Ops.IntAndDoubleToDouble) but that
performs extra work of assigning elements which I don't need. I'd like
to be able to reason about immutability, and replace* methods prevents
that.

--
David J. Biesack SAS Institute Inc.
(919) 531-7771 SAS Campus Drive
http://www.sas.com Cary, NC 27513
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: ThreadPoolExecutor corePoolSize incompatibility between backport and j.u.c.

2008-08-16T11:59:17Z

It is in the JavaDoc. Setting the core size to 1 only fixed the problem by making one thread available, but it will never grow. If you really want this behavior, there are tricks to do it.

---

Core and maximum pool sizes
A ThreadPoolExecutor will automatically adjust the pool size (see getPoolSize()) according to the bounds set by corePoolSize (see getCorePoolSize()) and maximumPoolSize (see getMaximumPoolSize()). When a new task is submitted in method execute(java.lang.Runnable), and fewer than corePoolSize threads are running, a new thread is created to handle the request, even if other worker threads are idle. If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full. By setting corePoolSize and maximumPoolSize the same, you create a fixed-size thread pool. By setting maximumPoolSize to an essentially unbounded value such as Integer.MAX_VALUE, you allow the pool to accommodate an arbitrary number of concurrent tasks. Most typically, core and maximum pool sizes are set only upon construction, but they may also be changed dynamically using setCorePoolSize(int) and setMaximumPoolSize(int).

Unbounded queues. Using an unbounded queue (for example a LinkedBlockingQueue without a predefined capacity) will cause new tasks to be queued in cases where all corePoolSize threads are busy. Thus, no more than corePoolSize threads will ever be created. (And the value of the maximumPoolSize therefore doesn't have any effect.) This may be appropriate when each task is completely independent of others, so tasks cannot affect each others execution; for example, in a web page server. While this style of queuing can be useful in smoothing out transient bursts of requests, it admits the possibility of unbounded work queue growth when commands continue to arrive on average faster than they can be processed.

----- Original Message ----
From: Greg Luck <gluck@...>
To: concurrency-interest@...
Sent: Saturday, August 16, 2008 4:54:53 AM
Subject: [concurrency-interest] ThreadPoolExecutor corePoolSize incompatibility between backport and j.u.c.

I am looking at moving the new version of ehcache to j.u.c, from backport, as part of dropping support for Java 1.4.

It turns out that all my tests which test code that uses backport's ThreadPoolExecutor never complete. The code which supplies the executor is shown below:

/**

* @return Gets the executor service. This is not publically accessible.

ThreadPoolExecutor getExecutorService() {

if (executorService == null) {

synchronized (this) {

//0, 10, 60000, ?, Integer.MAXVALUE

executorService = new ThreadPoolExecutor(0,10,

60000, TimeUnit.MILLISECONDS, new LinkedBlockingQueue());

}

return executorService;

}

Without understanding exactly why, I tried changing the corePoolSize to 1. This fixed the problem. My question is why? There is nothing in the JavaDoc I can see which says you must use a minimum of 1.

And I am now worried that j.u.c. is flaky in Java 5. Any comments from the list would be much appreciated.

Regards

Greg Luck

web: http://gregluck.com

skype: gregrluck

yahoo: gregrluck

mobile: +61 408 061 622

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

Re: ThreadPoolExecutor corePoolSize incompatibility between backport and j.u.c.

2008-08-16T07:53:26Z

the problem is most likely due to a particular behavior on juc: it
only creates threads when the queue is full. Im not sure it needs
fixing (it suggests so) or if its already fixed in jdk7

On Sat, Aug 16, 2008 at 9:34 AM, Martin Buchholz <martinrb@...> wrote:

> Many bugs in ThreadPoolExecutor were fixed during late JDK6 and early JDK7.
> Can you try a recent JDK7 first and see if the problem is resolved?
>
> Martin
>
> On Sat, Aug 16, 2008 at 4:54 AM, Greg Luck <gluck@...> wrote:
>> I am looking at moving the new version of ehcache to j.u.c, from backport,
>> as part of dropping support for Java 1.4.
>> It turns out that all my tests which test code that uses backport's
>> ThreadPoolExecutor never complete. The code which supplies the executor is
>> shown below:
>> /**
>> * @return Gets the executor service. This is not publically accessible.
>> */
>> ThreadPoolExecutor getExecutorService() {
>> if (executorService == null) {
>> synchronized (this) {
>> //0, 10, 60000, ?, Integer.MAXVALUE
>> executorService = new ThreadPoolExecutor(0,10,
>> 60000, TimeUnit.MILLISECONDS, new
>> LinkedBlockingQueue());
>> }
>> }
>> return executorService;
>> }
>>
>> Without understanding exactly why, I tried changing the corePoolSize to 1.
>> This fixed the problem. My question is why? There is nothing in the JavaDoc
>> I can see which says you must use a minimum of 1.
>> And I am now worried that j.u.c. is flaky in Java 5. Any comments from the
>> list would be much appreciated.
>>
>> Regards
>>
>> Greg Luck
>>
>> web: http://gregluck.com
>> skype: gregrluck
>> yahoo: gregrluck
>> mobile: +61 408 061 622
>>
>>
>>
>> _______________________________________________
>> 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
>

--
[]'s
Marcelo Takeshi Fukushima
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: ThreadPoolExecutor corePoolSize incompatibility between backport and j.u.c.

2008-08-16T05:34:14Z

Many bugs in ThreadPoolExecutor were fixed during late JDK6 and early JDK7.
Can you try a recent JDK7 first and see if the problem is resolved?

Martin

On Sat, Aug 16, 2008 at 4:54 AM, Greg Luck <gluck@...> wrote:

> I am looking at moving the new version of ehcache to j.u.c, from backport,
> as part of dropping support for Java 1.4.
> It turns out that all my tests which test code that uses backport's
> ThreadPoolExecutor never complete. The code which supplies the executor is
> shown below:
> /**
> * @return Gets the executor service. This is not publically accessible.
> */
> ThreadPoolExecutor getExecutorService() {
> if (executorService == null) {
> synchronized (this) {
> //0, 10, 60000, ?, Integer.MAXVALUE
> executorService = new ThreadPoolExecutor(0,10,
> 60000, TimeUnit.MILLISECONDS, new
> LinkedBlockingQueue());
> }
> }
> return executorService;
> }
>
> Without understanding exactly why, I tried changing the corePoolSize to 1.
> This fixed the problem. My question is why? There is nothing in the JavaDoc
> I can see which says you must use a minimum of 1.
> And I am now worried that j.u.c. is flaky in Java 5. Any comments from the
> list would be much appreciated.
>
> Regards
>
> Greg Luck
>
> web: http://gregluck.com
> skype: gregrluck
> yahoo: gregrluck
> mobile: +61 408 061 622
>
>
>
> _______________________________________________
> 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

ThreadPoolExecutor corePoolSize incompatibility between backport and j.u.c.

2008-08-16T04:54:53Z

I am looking at moving the new version of ehcache to j.u.c, from backport, as part of dropping support for Java 1.4.

It turns out that all my tests which test code that uses backport's ThreadPoolExecutor never complete. The code which supplies the executor is shown below:

/**

* @return Gets the executor service. This is not publically accessible.

ThreadPoolExecutor getExecutorService() {

if (executorService == null) {

synchronized (this) {

//0, 10, 60000, ?, Integer.MAXVALUE

executorService = new ThreadPoolExecutor(0,10,

60000, TimeUnit.MILLISECONDS, new LinkedBlockingQueue());

}

return executorService;

}

And I am now worried that j.u.c. is flaky in Java 5. Any comments from the list would be much appreciated.

Regards

Greg Luck

web: http://gregluck.com

skype: gregrluck

yahoo: gregrluck

mobile: +61 408 061 622

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

Re: Doubt on happens-before and I/O operations.

2008-08-15T08:13:55Z

Fabio Cechinel Veronez wrote:

> Hello all,
>
> I have a doubt (maybe a dummy one) about happens-before relation and
> I/O operations.
>
> In the following example code.
>
> 01: class FileItem {
> 02: private final File target;
> 03: private volatile boolean written = false;
> 04:
> 05: public FileItem(File target) {
> 06: this.target = target;
> 07: }
> 08:
> 09: public void initialize() throws IOException {
> 11: if (written)
> 12: return;
> 13: OutputStream out = new FileOutputStream(target);
> 14: try {
> 15: byte[] content = // retrieves the content from somewhere ...
> 16: out.write(content);
> 17: } finally {
> 18: out.close();
> 19: }
> 20: written = true;
> 21: }
> 22:
> 23: public InputStream stream() throws IOException {
> 24: if (!written)
> 25: throw new IllegalStateException("unwritten data");
> 26: return new FileInputStream(target);
> 27: }
> 28: }
>
> Is it safe to say that once a Thread X reachs line 26 the content was
> completely written into the 'target' file or is it possible to have
> any reordering concerning the write on 'written' field (line 20) and
> the output operation?
>
> Thanks in advance.
>

It s possible for two threads (or more) to be simultaneously executing
lines 13 - 20. The first one to reach line 20 will set written to true,
but the second thread will still be writing data. So the file may be
incomplete or may contain multiple copies of the data. I would not
recommend using volatile in this way.

Mark Thornton

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

Doubt on happens-before and I/O operations.

2008-08-15T07:32:07Z

Hello all,

I have a doubt (maybe a dummy one) about happens-before relation and
I/O operations.

In the following example code.

01: class FileItem {
02: private final File target;
03: private volatile boolean written = false;
04:
05: public FileItem(File target) {
06: this.target = target;
07: }
08:
09: public void initialize() throws IOException {
11: if (written)
12: return;
13: OutputStream out = new FileOutputStream(target);
14: try {
15: byte[] content = // retrieves the content from somewhere ...
16: out.write(content);
17: } finally {
18: out.close();
19: }
20: written = true;
21: }
22:
23: public InputStream stream() throws IOException {
24: if (!written)
25: throw new IllegalStateException("unwritten data");
26: return new FileInputStream(target);
27: }
28: }

Is it safe to say that once a Thread X reachs line 26 the content was
completely written into the 'target' file or is it possible to have
any reordering concerning the write on 'written' field (line 20) and
the output operation?

Thanks in advance.

--
Fabio Cechinel Veronez
Bacharel em Ciências da Computação - UFSC
Sun Certified Programmer For The Java 2 Platform 1.4

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

concurrency-interest now archived on MarkMail

2008-08-12T20:53:34Z

The concurrency-interest list is now archived using the most excellent
MarkMail mail navigator, developed by Jason Hunter of MarkLogic.

http://concurrency.markmail.org/

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

Re: Single producer, single consumer: unexpected delays for producer

2008-08-12T13:42:14Z

Daniel Harvey wrote:
> Having tested today, I found that performing:
> for (;;) queue.take();
> causes very little more contention that the best scenario, and much less
> than when the socket.write() is being performed.

Have you tried putting another queue in place to send the writes off to another
thread? This would let you have more than one thread doing encodes() and might
actually allow some overlapping I/O and CPU too, which will be a throughput
improvement.

I also didn't see whether you had used CTRL-\ or kill -3 <jvmpid> to get some
stack traces to see if they revealed the threads always "stuck" at the same
spot, or perhaps a "waiting to lock" state that might indicate, better, what the
contentious resource is.

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

Re: Single producer, single consumer: unexpected delays for producer

2008-08-12T11:55:51Z

Having tested today, I found that performing:
for (;;) queue.take();
causes very little more contention that the best scenario, and much
less than when the socket.write() is being performed.

On Aug 11, 2008, at 8:50 PM, David Holmes wrote:

> Dan,
>
> Your second case isn't a continuous take() because it does:
>
> ByteBuffer bytes = encoder.encode(chars);
>
> that might take sufficient time for the producer to produce the
> next item
> (or two) with no contention.
>
> That's why I said that I would expect:
>
> for(;;) queue.take();
>
> to also cause maximum contention.
>
> David
>
>> -----Original Message-----
>> From: Daniel Harvey [mailto:dharvey@...]
>> Sent: Tuesday, 12 August 2008 10:48 AM
>> To: dholmes@...
>> Cc: concurrency-interest@...
>> Subject: Re: [concurrency-interest] Single producer,single consumer:
>> unexpected delays for producer
>>
>>
>> I'm not sure whether the queue size is non-zero in the fast case,
>> though I will test this tomorrow and report back. But something
>> doesn't make sense here because in the second case - the continuous
>> take() one - there should be an even greater likelihood of
>> encountering a non-empty queue... I really feel like the issue has to
>> be the socket write interfering with the thread-signaling of the
>> existence of a new message to process: I'm fairly sure that I could
>> add other time-taking calculations to the consumer thread (in place
>> of the socket.write() ) and they wouldn't slow down the producer.
>> I'll add something like this tomorrow and see whether my assessment
>> is accurate.
>>
>> The following isn't a very elegant solution, and it might hammer the
>> CPU too much, but I have experimented with having the consumer do a
>> periodic sending of a batch of messages, then sleeping and checking
>> for new messages every few ms (rather than waiting), and repeating.
>> With this approach there's no signal between threads and I think the
>> producer operates much faster (even with the necessary
>> synchronization). Of course I am adding latency, but if throughput is
>> the bottom line, it might be a useable solution.
>>
>> -Dan
>>
>> On Aug 11, 2008, at 8:29 PM, David Holmes wrote:
>>
>>> Dan,
>>>
>>>> 3) I put some code in to keep track of how many messages are
>>>> typically in the queue when the consumer thread finishes it's
>>>> take(),
>>>> and it is typically 0... ie the majority (around 80-90%) of the
>>>> time
>>>> a single message is being removed from the queue.
>>>
>>> Okay so that explains the contention. The producer is expending
>>> effort
>>> acquiring two locks and waking up the producer.
>>>
>>>> that's still a big difference... specifically:
>>>>
>>>> for (;;) {
>>>> CharBuffer chars = CharBuffer.wrap(queue.take());
>>>> ByteBuffer bytes = encoder.encode(chars);
>>>> socketChannel.write(bytes);
>>>> }
>>>>
>>>> causes queue.offer(message) to take 3 times longer to execute
>>>> than if
>>>> the consumer executes:
>>>>
>>>> for (;;) {
>>>> CharBuffer chars = CharBuffer.wrap(queue.take());
>>>> ByteBuffer bytes = encoder.encode(chars);
>>>> }
>>>
>>> Can I assume that in the fast case the queue size is not normally
>>> zero? If
>>> so my theory here is that when the consumer uses the socketChannel
>>> it is
>>> introducing additional contention with the prodcuer that keeps the
>>> producer
>>> and conumer effectively in lock-step:
>>> - consumer blocks on take()
>>> - producer gets item and does offer() and has to wakeup consumer
>>> - consumer processes item and uses resources needed by producer
>>> - producer is blocked or delayed getting next item
>>> - consumer calls take() again and blocks
>>> - producer produces and calls offer() and has to wakeup consumer
>>> - repeat
>>>
>>> However in that case I would expect:
>>> for(;;) queue.take();
>>> to also impose maximum contention with the producer.
>>>
>>> David
>>>
>>
>

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

lock acquire/release order in CHM.size()

2008-08-12T11:52:48Z

Just a mild curiosity of mine that folks on this list might have insight
into...

When operations like size() on j.u.c.ConcurrentHashMap have to resort to
locking, the locks are acquired and released like so:

for (int i = 0; i < segments.length; ++i)
segments[i].lock();
/* ... */
for (int i = 0; i < segments.length; ++i)
segments[i].unlock();

The curious bit is that the last lock obtained is not the first lock
released. I'm not suggesting there is anything wrong with that, but I was
wondering if there is a specific rationale for that? I suppose two threads
going through those loops would be less serialized since one thread could
start acquiring in lock step with the other thread doing the unlocks.

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