[concurrency-interest] Concurrency-interest Digest, Vol 87,

Sandeep Bansal sandeep.bansal85 at gmail.com
Mon Apr 16 15:22:56 EDT 2012


 Issue 27
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0377691237=="

--===============0377691237==
Content-Type: multipart/alternative;
boundary="897404883-1652871492-1334601360=:99294"

--897404883-1652871492-1334601360=:99294
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

What happens in your algorithm if two threads are trying to take the
same lock simultaneously? Does the algorithm itself uses critical
section(locks??) to handle this case?

Thanks,
Sandeep
Sent from my Windows Phone
From: Rohit Kumar
Sent: 17/04/2012 12:08 AM
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Concurrency-interest Digest, Vol
87, Issue 27
Hans,Nathan,
=C2=A0
I am not aware of anything like Gadara yet. My implementation assumes that =
there are no synchnonized keywords (implicit locks)=C2=A0in your program. I=
t requires you to use explicit locks (e.g. Lock class in java concurrent ap=
i). There is no background thread running here. The deadlock-check happens =
at each lock acquisition request; it runs an algorithms internally to see i=
f there are any cycles formed in the lock-acquisition graph. If yes, it doe=
sn't let you acquire the lock but throws an exception. You can catch this e=
xception and take necessary steps to re-acquire all the locks once again or=
 whatever you want. The program is written in java and it is hardly 270 lin=
es of code.
=C2=A0
Finally where do I need to present this writeup ?
=C2=A0
Thanks & Regards,
Rohit Kumar

From: "concurrency-interest-request at cs.oswego.edu" <concurrency-interest-re=
quest at cs.oswego.edu>
To: concurrency-interest at cs.oswego.edu=20
Sent: Monday, 16 April 2012 10:50 PM
Subject: Concurrency-interest Digest, Vol 87, Issue 27

Send Concurrency-interest mailing list submissions to
=C2=A0=C2=A0=C2=A0 concurrency-interest at cs.oswego.edu

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0=C2=A0=C2=A0 http://cs.oswego.edu/mailman/listinfo/concurrency-intere=
st
or, via email, send a message with subject or body 'help' to
=C2=A0=C2=A0=C2=A0 concurrency-interest-request at cs.oswego.edu

You can reach the person managing the list at
=C2=A0=C2=A0=C2=A0 concurrency-interest-owner at cs.oswego.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Concurrency-interest digest..."


Today's Topics:

=C2=A0 1. Re: CountedCompleters (Wolfgang Baltes)
=C2=A0 2. Re: Java Deadlocks prevented (Boehm, Hans)
=C2=A0 3. Re: Java Deadlocks prevented (Nathan Reynolds)
=C2=A0 4. Re: Concurrency-interest Digest, Vol 87,=C2=A0=C2=A0=C2=A0 Issue =
26 (Java
=C2=A0 =C2=A0 =C2=A0 deadlock prevented) (Rohit Kumar)


----------------------------------------------------------------------

Message: 1
Date: Mon, 16 Apr 2012 18:01:50 +0200
From: Wolfgang Baltes <wolfgang.baltes at laposte.net>
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] CountedCompleters
Message-ID: <4F8C426E.6090704 at laposte.net>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

I apologize for a mistake in the last paragraph of my memo: using=20
quietlyJoinUnforked() in the SDK7 sample code for MergeSort does have a=20
non-negligible performance impact (not no impact as stated). There is=20
better performance in case of recursions which produce many tasks that=20
are not explicitly forked, and it reduces the number of extra threads=20
significantly, allowing larger problems to be solved with smaller memory=20
footprint.

Wolfgang.

On 2012-04-16 16:48, Wolfgang Baltes wrote:
> Thanks, Doug, for a this addition to the FJ framework. I think that
> CountedCompleter will address the needs of an entire class of
> applications in an efficient and simple to use manner.
>
> I used the code and noticed that method doJoin() has become more
> effective in avoiding blocking threads, and as a result fewer extra
> threads are created. I found the performance, compared to
> RecursiveAction, to be equal or insignificantly different. This
> reduces the problem described in item 3 below.
>
> However, at the same time, CountedCompleter does not fully satisfy the
> needs for a class of problems I work on. To this end, here are a few
> enhancements I would like to suggest:
>
> 1: Symmetrically to onCompletion(), provide
> onExceptionalCompletion(Throwable). This allows filtering exception
> propagation. There are cases where the propagation of the exception is
> desired, and others where a corrective action is taken instead, such
> as a retry.
>
> 2: As a further enhancement to 1: enable any Throwable, including
> checked exceptions. This allows the use of a CountedCompleter as a
> CompletionHandler for asynchronous IO operations or as a wrapper for
> MethodHandles (which throw Throwable) without adding extra logic to
> capture and convert an IO exception. I read the documentation which
> explains why this is currently limited to unchecked exceptions. While
> I can agree with this in general, I feel the argument is weak for
> CountedCompleter if it is there to support asynchronous tasks/events.
> (May I add that using this type of framework is not for the
> faint-hearted anyway!?)
>
> 3: Provide a method to join a task that is not forked and/or not
> completable, while minimizing worker thread blocking. For example,
> CountedCompleter allows creating chains of dependent tasks. Unless the
> ultimate task (the last in the chain) is forked/exists on the task
> stack AND can complete because all dependencies are resolved, joining
> it will block the worker thread. I noticed (and my testing is limited
> to a few test cases and therefore not representative) the blocking and
> the creation of other worker threads, ultimately running out of memory
> or reaching the thread count limit. If this task is not forked, then
> join()/quietlyJoin() will block the worker thread. The following code
> is my (inexpert) attempt to provide a remedy. It is based on the
> assumption that a task that depends on others for completion is not
> forked until all dependencies are resolved. For example, a
> CountedCompleter implementing CompletionHandler would fork itself
> ("implicit fork") when the IO operation is done. This works very well
> in my test cases, but at this time I would not claim it to be
> universally applicable or error free. It is shown here more to
> demonstrate the attempt rather than as a reference implementation.
> With access to private data structures, this can be done more
> elegantly and more reliably.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 static final int RETRIES =3D 16;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 static final long WAIT_TIMEOUT =3D 1_000;=C2=
=A0 =C2=A0 // Timeout in
> microseconds.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public final void quietlyJoinUnforked() {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this.doJoinUnforked(false);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public final void quietlyJoinUnforkedInterrupt=
ibly()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 throws InterruptedException {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (this.doJoinUnforked(true)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw new Interrup=
tedException();
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public final boolean doJoinUnforked(final bool=
ean
> interruptibly) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int retries =3D RETRIES;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean wasInterrupted =3D false=
;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 while (!this.isDone()) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ForkJoinTask<?> t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((t =3D pollTas=
k()) !=3D null) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t.qu=
ietlyInvoke();
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (=
t =3D=3D this) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 break;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 else {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (=
retries-- > 0) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Thread.yield();
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 continue;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wasI=
nterrupted =3D Thread.interrupted();
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 try =
{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // get(...) is used as a timed join(). It is
> assumed that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // other code will perform get() on this task
> to retrieve
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // the task's result or exception.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 this.get(WAIT_TIMEOUT, TimeUnit.MICROSECONDS);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 break;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 catc=
h (final InterruptedException consumed) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 if (!interruptibly) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 wasInterrupted =3D true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 continue;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 return true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 catc=
h (final ExecutionException ignored) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // See comment on get() above.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 break;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 catc=
h (final TimeoutException ignored) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 continue;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retries =3D RETRIE=
S;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (wasInterrupted && !interrupt=
ibly) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thread.currentThre=
ad().interrupt();
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return wasInterrupted;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
> As already mentioned this works quite well in a number of cases. For
> example, adding this method to the example MergeSort code and calling
> quietlyJoinUnforked(), results in the same overall performance,
> reduces the number of extra blocked worker threads to 1 if any
> (instead of up to 8 for the unmodified code; on a PC with 4
> hyper-threading cores/8 threads), and allows for some extra
> (recreational?) freedom in joining the right and left sub-tasks in any
> order. It works in cases where no sub-task is forked explicitly. I
> observed that worker thread blocking only occurs towards the end of a
> large recursion, suggesting that worker threads only block - as
> intended - when there is no other work available (sometimes while
> implicit forking has not yet happened).
>
> Wolfgang.
>
>
>
> On 2012-04-09 16:16, Doug Lea wrote:
>>
>> After sitting on multiple variations for months, I committed
>> CountedCompleter, a completion-based flavor of ForkJoinTask.
>>
>> As mentioned a few times over the past year, the main motivation
>> is to better support tasks that perform IO or other base
>> actions that may (or may not) take a lot of time to execute.
>> As is the case with JDK7 async IO and other completion-based
>> frameworks, the most common path to efficiency is for such tasks
>> to arrange continuation actions that occur upon their completion.
>> The main twist for CountedCompleters is that continuations
>> might be dependent on multiple actions, not just one. (Or in
>> other words, the continuations must be preceded by a specialized,
>> "bottom-up" form of join.)
>>
>> The CountedCompleter abstract class provides a minimal basis
>> for these kinds of tasks. While some of the mechanics are
>> reminiscent of other FJ-like frameworks such as Intel TBB,
>> CountedCompleters are designed to fit smoothly with other
>> kinds of ForkJoinTasks (like RecursiveActions), and so still
>> allow people to use the more pleasant Future-style conventions
>> rather than count-based bottom-up joining unless they need them.
>> At the same time, the CountedCompleter class exposes enough
>> mechanics to allow all sorts of tweaks that people can use
>> to improve performance.
>> In particular, in addition to usually being the best way to deal
>> with IO etc bound tasks, CountedCompleters sometimes fare better
>> than RecursiveActions in programs that entail lots of garbage
>> collection because GC can have similar impact on task variability.
>>
>> Even though targeted for JDK8, versions of CountedCompleter
>> appear in the jsr166y and main repositories, not jsr166e. This is
>> because they require a non-public hook into modified ForkJoinTask
>> exception handling mechanics in order to properly propagate
>> exceptional completions. For sources, docs, and jar files, see
>> the usual links at
>> http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
>>
>> The API docs include more details and some examples:
>> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/Counte=
dCompleter.html
>>
>>
>> I also added a few (with more to come) test/demo programs that
>> illustrate
>> other usages. See CCBoxedLongSort and CCJacobi in
>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/
>>
>> Please try these out. As always, comments and suggestions
>> (hopefully based on usage experience) would be welcome.
>>
>> -Doug
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


------------------------------

Message: 2
Date: Mon, 16 Apr 2012 16:38:00 +0000
From: "Boehm, Hans" <hans.boehm at hp.com>
To: Andrew Haley <aph at redhat.com>,
=C2=A0=C2=A0=C2=A0 "concurrency-interest at cs.oswego.edu"
=C2=A0=C2=A0=C2=A0 <concurrency-interest at cs.oswego.edu>
Subject: Re: [concurrency-interest] Java Deadlocks prevented
Message-ID:
=C2=A0=C2=A0=C2=A0 <A3E67C2071F49C4CBC4F17E6D77CDDD235543F5B at G4W3299.americ=
as.hpqcorp.net>
=C2=A0=C2=A0=C2=A0=20
Content-Type: text/plain; charset=3D"us-ascii"

Important questions to consider when you write it up:

How does it compare to something like Gadara that uses whole program analys=
is and scheduling to avoid lock-based deadlocks?=C2=A0 (Hopefully it doesn'=
t need whole program analysis.)=C2=A0 Other deadlock avoidance schemes?

Once you detect a potential deadlock, how do you recover?=C2=A0 Or can you =
always schedule so that the possibility doesn't arise?

Hans

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-
> interest-bounces at cs.oswego.edu] On Behalf Of Andrew Haley
> Sent: Monday, April 16, 2012 4:34 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Java Deadlocks prevented
>=20
> On 04/16/2012 12:06 PM, Rohit Kumar wrote:
>=20
> > I have found a way of preventing deadlocks in java. The
> > methodology(which is code) completely prevents the deadlock from
> > occuring by detecting it in advance. This can be used across the
> > systems seamlessly.
> >
> > Kindly let me know what I need to do next. I want this to be part of
> > next jdk release. I am writing this email as I have no idea what I
> > need to do next to bring it into limelight.
>=20
> Write it up, maybe present it to a conference, and wait for feedback.
> That's how it always works.=C2=A0 If your idea really works, people will
> use it.
>=20
> Andrew.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



------------------------------

Message: 3
Date: Mon, 16 Apr 2012 10:11:00 -0700
From: Nathan Reynolds <nathan.reynolds at oracle.com>
To: "Boehm, Hans" <hans.boehm at hp.com>
Cc: "concurrency-interest at cs.oswego.edu"
=C2=A0=C2=A0=C2=A0 <concurrency-interest at cs.oswego.edu>
Subject: Re: [concurrency-interest] Java Deadlocks prevented
Message-ID: <4F8C52A4.70002 at oracle.com>
Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed"

Deadlock prevention is very valuable.=C2=A0 It means deadlock prone code=20
won't bring down a production server and cost the company millions in=20
down time.=C2=A0 It means consumers won't kill the process and request a re=
fund.

How much does deadlock prevention cost?=C2=A0 Is the cost on the thread tha=
t=20
acquires locks or is it in a background thread?

Each time processors or systems increase the number of cores, I find we=20
have to do a round of lock contention fixing.=C2=A0 I have only seen 1 lock=
=20
at a time be the bottleneck in the system.=C2=A0 Does deadlock prevention=
=20
increase the critical region of locks?=C2=A0 If so, this will definitely=20
reduce the scalability of the system if it impacts the 1 bottlenecking lock=
.

Lock performance is a very important consideration.=C2=A0 Locks have evolve=
d=20
from fat locks (i.e trips into the OS kernel) to thin locks (i.e. spin=20
and CAS in user mode) to biased/lazy locks (i.e. no CAS and an=20
indefinite lock owner).=C2=A0 All of this was done to reduce the performanc=
e=20
overhead of locks.=C2=A0 How does deadlock prevention impact the performanc=
e=20
of biased, thin and fat locks?=C2=A0 I am not as concerned about fat lock=
=20
performance since most of the time the thread is going to block.

Nathan Reynolds=20
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |=20
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 4/16/2012 9:38 AM, Boehm, Hans wrote:
> Important questions to consider when you write it up:
>
> How does it compare to something like Gadara that uses whole program anal=
ysis and scheduling to avoid lock-based deadlocks?=C2=A0 (Hopefully it does=
n't need whole program analysis.)=C2=A0 Other deadlock avoidance schemes?
>
> Once you detect a potential deadlock, how do you recover?=C2=A0 Or can yo=
u always schedule so that the possibility doesn't arise?
>
> Hans
>
>> -----Original Message-----
>> From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-
>> interest-bounces at cs.oswego.edu] On Behalf Of Andrew Haley
>> Sent: Monday, April 16, 2012 4:34 AM
>> To: concurrency-interest at cs.oswego.edu
>> Subject: Re: [concurrency-interest] Java Deadlocks prevented
>>
>> On 04/16/2012 12:06 PM, Rohit Kumar wrote:
>>
>>> I have found a way of preventing deadlocks in java. The
>>> methodology(which is code) completely prevents the deadlock from
>>> occuring by detecting it in advance. This can be used across the
>>> systems seamlessly.
>>>
>>> Kindly let me know what I need to do next. I want this to be part of
>>> next jdk release. I am writing this email as I have no idea what I
>>> need to do next to bring it into limelight.
>> Write it up, maybe present it to a conference, and wait for feedback.
>> That's how it always works.=C2=A0 If your idea really works, people will
>> use it.
>>
>> Andrew.
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120=
416/7ea89bb3/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 17 Apr 2012 01:20:15 +0800 (SGT)
From: Rohit Kumar <rohitk242 at yahoo.co.in>
To: "concurrency-interest at cs.oswego.edu"
=C2=A0=C2=A0=C2=A0 <concurrency-interest at cs.oswego.edu>
Subject: Re: [concurrency-interest] Concurrency-interest Digest, Vol
=C2=A0=C2=A0=C2=A0 87,=C2=A0=C2=A0=C2=A0 Issue 26 (Java deadlock prevented)
Message-ID:
=C2=A0=C2=A0=C2=A0 <1334596815.27848.YahooMailNeo at web193403.mail.sg3.yahoo.=
com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Andrew:
?
Thanks for the reply. Can you kindly let me know where do I need to present=
 it ? Where will the conference be held ? Can I present it online or I have=
 to come in person ?
?
Waiting for your early reply once again.
?
Thanks & Regards,
Rohit Kumar

From: "concurrency-interest-request at cs.oswego.edu" <concurrency-interest-re=
quest at cs.oswego.edu>
To: concurrency-interest at cs.oswego.edu=20
Sent: Monday, 16 April 2012 9:30 PM
Subject: Concurrency-interest Digest, Vol 87, Issue 26

Send Concurrency-interest mailing list submissions to
??? concurrency-interest at cs.oswego.edu

To subscribe or unsubscribe via the World Wide Web, visit
??? http://cs.oswego.edu/mailman/listinfo/concurrency-interest
or, via email, send a message with subject or body 'help' to
??? concurrency-interest-request at cs.oswego.edu

You can reach the person managing the list at
??? concurrency-interest-owner at cs.oswego.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Concurrency-interest digest..."


Today's Topics:

? 1. (no subject) (Rohit Kumar)
? 2. Java Deadlocks prevented (Rohit Kumar)
? 3. Re: Java Deadlocks prevented (Andrew Haley)
? 4. Re: CountedCompleters (Wolfgang Baltes)


----------------------------------------------------------------------

Message: 1
Date: Mon, 16 Apr 2012 19:03:59 +0800 (SGT)
From: Rohit Kumar <rohitk242 at yahoo.co.in>
To: "concurrency-interest at cs.oswego.edu"
??? <concurrency-interest at cs.oswego.edu>
Cc: "concurrency-interest-owner at cs.oswego.edu"
??? <concurrency-interest-owner at cs.oswego.edu>
Subject: [concurrency-interest] (no subject)
Message-ID:
??? <1334574239.81244.YahooMailNeo at web193402.mail.sg3.yahoo.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Hi All,
?
I have found a way of preventing deadlocks in java. The methodology(which i=
s code) completely prevents the deadlock from accuring by detecting it in a=
dvance. This can be used across the systems seamlessly.=20
?
Kindly let me know what I need to do next. I want this to be part of next j=
dk release.
?
Thanks & Regards,
Rohit Kumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120=
416/a6588341/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 16 Apr 2012 19:06:22 +0800 (SGT)
From: Rohit Kumar <rohitk242 at yahoo.co.in>
To: "concurrency-interest at cs.oswego.edu"
??? <concurrency-interest at cs.oswego.edu>
Cc: "concurrency-interest-owner at cs.oswego.edu"
??? <concurrency-interest-owner at cs.oswego.edu>
Subject: [concurrency-interest] Java Deadlocks prevented
Message-ID:
??? <1334574382.90584.YahooMailNeo at web193403.mail.sg3.yahoo.com>
Content-Type: text/plain; charset=3D"utf-8"



Hi All,

I have found a way of preventing deadlocks in java. The methodology(which i=
s code) completely prevents the deadlock from occuring by detecting it in a=
dvance. This can be used across the systems seamlessly.=20

Kindly let me know what I need to do next. I want this to be part of next j=
dk release. I am writing this email as I have no idea what I need to do nex=
t to bring it into limelight.

Thanks & Regards,
Rohit Kumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120=
416/064a4873/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 16 Apr 2012 12:33:45 +0100
From: Andrew Haley <aph at redhat.com>
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Java Deadlocks prevented
Message-ID: <4F8C0399.8040301 at redhat.com>
Content-Type: text/plain; charset=3DISO-8859-1

On 04/16/2012 12:06 PM, Rohit Kumar wrote:

> I have found a way of preventing deadlocks in java. The
> methodology(which is code) completely prevents the deadlock from
> occuring by detecting it in advance. This can be used across the
> systems seamlessly.
>=20
> Kindly let me know what I need to do next. I want this to be part of
> next jdk release. I am writing this email as I have no idea what I
> need to do next to bring it into limelight.

Write it up, maybe present it to a conference, and wait for feedback.
That's how it always works.? If your idea really works, people will
use it.

Andrew.


------------------------------

Message: 4
Date: Mon, 16 Apr 2012 16:48:31 +0200
From: Wolfgang Baltes <wolfgang.baltes at laposte.net>
To: "Concurrency-interest at cs.oswego.edu"
??? <Concurrency-interest at cs.oswego.edu>
Subject: Re: [concurrency-interest] CountedCompleters
Message-ID: <4F8C313F.2080308 at laposte.net>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

Thanks, Doug, for a this addition to the FJ framework. I think that=20
CountedCompleter will address the needs of an entire class of=20
applications in an efficient and simple to use manner.

I used the code and noticed that method doJoin() has become more=20
effective in avoiding blocking threads, and as a result fewer extra=20
threads are created. I found the performance, compared to=20
RecursiveAction, to be equal or insignificantly different. This reduces=20
the problem described in item 3 below.

However, at the same time, CountedCompleter does not fully satisfy the=20
needs for a class of problems I work on. To this end, here are a few=20
enhancements I would like to suggest:

1: Symmetrically to onCompletion(), provide=20
onExceptionalCompletion(Throwable). This allows filtering exception=20
propagation. There are cases where the propagation of the exception is=20
desired, and others where a corrective action is taken instead, such as=20
a retry.

2: As a further enhancement to 1: enable any Throwable, including=20
checked exceptions. This allows the use of a CountedCompleter as a=20
CompletionHandler for asynchronous IO operations or as a wrapper for=20
MethodHandles (which throw Throwable) without adding extra logic to=20
capture and convert an IO exception. I read the documentation which=20
explains why this is currently limited to unchecked exceptions. While I=20
can agree with this in general, I feel the argument is weak for=20
CountedCompleter if it is there to support asynchronous tasks/events.=20
(May I add that using this type of framework is not for the=20
faint-hearted anyway!?)

3: Provide a method to join a task that is not forked and/or not=20
completable, while minimizing worker thread blocking. For example,=20
CountedCompleter allows creating chains of dependent tasks. Unless the=20
ultimate task (the last in the chain) is forked/exists on the task stack=20
AND can complete because all dependencies are resolved, joining it will=20
block the worker thread. I noticed (and my testing is limited to a few=20
test cases and therefore not representative) the blocking and the=20
creation of other worker threads, ultimately running out of memory or=20
reaching the thread count limit. If this task is not forked, then=20
join()/quietlyJoin() will block the worker thread. The following code is=20
my (inexpert) attempt to provide a remedy. It is based on the assumption=20
that a task that depends on others for completion is not forked until=20
all dependencies are resolved. For example, a CountedCompleter=20
implementing CompletionHandler would fork itself ("implicit fork") when=20
the IO operation is done. This works very well in my test cases, but at=20
this time I would not claim it to be universally applicable or error=20
free. It is shown here more to demonstrate the attempt rather than as a=20
reference implementation. With access to private data structures, this=20
can be done more elegantly and more reliably.

? ? ? ? static final int RETRIES =3D 16;
? ? ? ? static final long WAIT_TIMEOUT =3D 1_000;? ? // Timeout in=20
microseconds.

? ? ? ? public final void quietlyJoinUnforked() {
? ? ? ? ? ? this.doJoinUnforked(false);
? ? ? ? }

? ? ? ? public final void quietlyJoinUnforkedInterruptibly()
? ? ? ? throws InterruptedException {
? ? ? ? ? ? if (this.doJoinUnforked(true)) {
? ? ? ? ? ? ? ? throw new InterruptedException();
? ? ? ? ? ? }
? ? ? ? }

? ? ? ? public final boolean doJoinUnforked(final boolean interruptibly) {
? ? ? ? ? ? int retries =3D RETRIES;
? ? ? ? ? ? boolean wasInterrupted =3D false;
? ? ? ? ? ? while (!this.isDone()) {
? ? ? ? ? ? ? ? ForkJoinTask<?> t;
? ? ? ? ? ? ? ? if ((t =3D pollTask()) !=3D null) {
? ? ? ? ? ? ? ? ? ? t.quietlyInvoke();
? ? ? ? ? ? ? ? ? ? if (t =3D=3D this) {
? ? ? ? ? ? ? ? ? ? ? ? break;
? ? ? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? else {
? ? ? ? ? ? ? ? ? ? if (retries-- > 0) {
? ? ? ? ? ? ? ? ? ? ? ? Thread.yield();
? ? ? ? ? ? ? ? ? ? ? ? continue;
? ? ? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? ? ? wasInterrupted =3D Thread.interrupted();
? ? ? ? ? ? ? ? ? ? try {
? ? ? ? ? ? ? ? ? ? ? ? // get(...) is used as a timed join(). It is=20
assumed that
? ? ? ? ? ? ? ? ? ? ? ? // other code will perform get() on this task=20
to retrieve
? ? ? ? ? ? ? ? ? ? ? ? // the task's result or exception.
? ? ? ? ? ? ? ? ? ? ? ? this.get(WAIT_TIMEOUT, TimeUnit.MICROSECONDS);
? ? ? ? ? ? ? ? ? ? ? ? break;
? ? ? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? ? ? catch (final InterruptedException consumed) {
? ? ? ? ? ? ? ? ? ? ? ? if (!interruptibly) {
? ? ? ? ? ? ? ? ? ? ? ? ? ? wasInterrupted =3D true;
? ? ? ? ? ? ? ? ? ? ? ? ? ? continue;
? ? ? ? ? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? ? ? ? ? return true;
? ? ? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? ? ? catch (final ExecutionException ignored) {
? ? ? ? ? ? ? ? ? ? ? ? // See comment on get() above.
? ? ? ? ? ? ? ? ? ? ? ? break;
? ? ? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? ? ? catch (final TimeoutException ignored) {
? ? ? ? ? ? ? ? ? ? ? ? continue;
? ? ? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? retries =3D RETRIES;
? ? ? ? ? ? }
? ? ? ? ? ? if (wasInterrupted && !interruptibly) {
? ? ? ? ? ? ? ? Thread.currentThread().interrupt();
? ? ? ? ? ? ? ? return false;
? ? ? ? ? ? }
? ? ? ? ? ? return wasInterrupted;
? ? ? ? }

As already mentioned this works quite well in a number of cases. For=20
example, adding this method to the example MergeSort code and calling=20
quietlyJoinUnforked(), results in the same overall performance, reduces=20
the number of extra blocked worker threads to 1 if any (instead of up to=20
8 for the unmodified code; on a PC with 4 hyper-threading cores/8=20
threads), and allows for some extra (recreational?) freedom in joining=20
the right and left sub-tasks in any order. It works in cases where no=20
sub-task is forked explicitly. I observed that worker thread blocking=20
only occurs towards the end of a large recursion, suggesting that worker=20
threads only block - as intended - when there is no other work available=20
(sometimes while implicit forking has not yet happened).

Wolfgang.



On 2012-04-09 16:16, Doug Lea wrote:
>
> After sitting on multiple variations for months, I committed
> CountedCompleter, a completion-based flavor of ForkJoinTask.
>
> As mentioned a few times over the past year, the main motivation
> is to better support tasks that perform IO or other base
> actions that may (or may not) take a lot of time to execute.
> As is the case with JDK7 async IO and other completion-based
> frameworks, the most common path to efficiency is for such tasks
> to arrange continuation actions that occur upon their completion.
> The main twist for CountedCompleters is that continuations
> might be dependent on multiple actions, not just one. (Or in
> other words, the continuations must be preceded by a specialized,
> "bottom-up" form of join.)
>
> The CountedCompleter abstract class provides a minimal basis
> for these kinds of tasks. While some of the mechanics are
> reminiscent of other FJ-like frameworks such as Intel TBB,
> CountedCompleters are designed to fit smoothly with other
> kinds of ForkJoinTasks (like RecursiveActions), and so still
> allow people to use the more pleasant Future-style conventions
> rather than count-based bottom-up joining unless they need them.
> At the same time, the CountedCompleter class exposes enough
> mechanics to allow all sorts of tweaks that people can use
> to improve performance.
> In particular, in addition to usually being the best way to deal
> with IO etc bound tasks, CountedCompleters sometimes fare better
> than RecursiveActions in programs that entail lots of garbage
> collection because GC can have similar impact on task variability.
>
> Even though targeted for JDK8, versions of CountedCompleter
> appear in the jsr166y and main repositories, not jsr166e. This is
> because they require a non-public hook into modified ForkJoinTask
> exception handling mechanics in order to properly propagate
> exceptional completions. For sources, docs, and jar files, see
> the usual links at=20
> http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
>
> The API docs include more details and some examples:
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/Counted=
Completer.html=20
>
>
> I also added a few (with more to come) test/demo programs that illustrate
> other usages. See CCBoxedLongSort and CCJacobi in
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/
>
> Please try these out. As always, comments and suggestions
> (hopefully based on usage experience) would be welcome.
>
> -Doug
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


------------------------------

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


End of Concurrency-interest Digest, Vol 87, Issue 26
****************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120=
417/75746dcb/attachment.html>

------------------------------

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


End of Concurrency-interest Digest, Vol 87, Issue 27
****************************************************
--897404883-1652871492-1334601360=:99294
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html><body><html><head><meta content=3D"text/html; charset=3Dutf-8" http-e=
quiv=3D"Content-Type"></head><body><div><div style=3D"font-family: Calibri,=
sans-serif; font-size: 11pt;">What happens in your algorithm if two threads=
 are trying to take the same lock simultaneously? Does the algorithm itself=
  uses critical section(locks??) to handle this case?<br><br>Thanks,<b=
r>Sandeep<br>Sent from my Windows Phone<br></div></div><hr><span style=3D"f=
ont-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">From: <=
/span><span style=3D"font-family: Tahoma,sans-serif; font-size: 10pt;">Rohi=
t Kumar</span><br><span style=3D"font-family: Tahoma,sans-serif; font-size:=
 10pt; font-weight: bold;">Sent: </span><span style=3D"font-family: Tahoma,=
sans-serif; font-size: 10pt;">17/04/2012 12:08 AM</span><br><span style=3D"=
font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">To: </=
span><span style=3D"font-family: Tahoma,sans-serif; font-size: 10pt;">concu=
rrency-interest at cs.oswego.edu</span><br><span style=3D"font-family: Tahoma,=
sans-serif; font-size: 10pt; font-weight: bold;">Subject: </span><span styl=
e=3D"font-family: Tahoma,sans-serif; font-size: 10pt;">Re: [concurrency-int=
erest] Concurrency-interest Digest, Vol 87, Issue 27</span><br><br></body><=
/html><div style=3D"color:#000; background-color:#fff; font-family:times ne=
w roman, new york, times, serif;font-size:12pt"><div style=3D"RIGHT: auto">=
<SPAN style=3D"RIGHT: auto">Hans,Nathan,</SPAN></div>
<div style=3D"RIGHT: auto"><SPAN style=3D"RIGHT: auto"></SPAN> </div>
<div style=3D"RIGHT: auto"><SPAN style=3D"RIGHT: auto">I am not aware of an=
ything like Gadara yet. My implementation assumes that there are no synchno=
nized keywords (implicit locks) in your program. It requires you to us=
e explicit locks (e.g. Lock class in java concurrent api). There is no back=
ground thread running here. The deadlock-check happens at each lock acquisi=
tion request; it runs an algorithms internally to see if there are any cycl=
es formed in the lock-acquisition graph. If yes, it doesn't let you acquire=
 the lock but throws an exception. You can catch this exception and take ne=
cessary steps to re-acquire all the locks once again or whatever you want. =
The program is written in java and it is hardly 270 lines of code.</SPAN></=
div>
<div style=3D"RIGHT: auto"><SPAN style=3D"RIGHT: auto"></SPAN> </div>
<div style=3D"RIGHT: auto"><SPAN style=3D"RIGHT: auto">Finally where do I n=
eed to present this writeup ?<VAR id=3Dyui-ie-cursor></VAR></SPAN></div>
<div style=3D"RIGHT: auto"><SPAN style=3D"RIGHT: auto"></SPAN> </div>
<div style=3D"RIGHT: auto"><SPAN style=3D"RIGHT: auto">Thanks & Regards=
,</SPAN></div>
<div style=3D"RIGHT: auto"><SPAN style=3D"RIGHT: auto">Rohit Kumar</SPAN></=
div>
<div><BR></div>
<DIV style=3D"FONT-FAMILY: times new roman, new york, times, serif; FONT-SI=
ZE: 12pt">
<DIV style=3D"FONT-FAMILY: times new roman, new york, times, serif; FONT-SI=
ZE: 12pt">
<DIV dir=3Dltr><FONT size=3D2 face=3DArial>
<DIV style=3D"BORDER-BOTTOM: #ccc 1px solid; BORDER-LEFT: #ccc 1px solid; P=
ADDING-BOTTOM: 0px; LINE-HEIGHT: 0; MARGIN: 5px 0px; PADDING-LEFT: 0px; PAD=
DING-RIGHT: 0px; HEIGHT: 0px; FONT-SIZE: 0px; BORDER-TOP: #ccc 1px solid; B=
ORDER-RIGHT: #ccc 1px solid; PADDING-TOP: 0px" class=3Dhr readonly=3D"true"=
 contenteditable=3D"false"></DIV><B><SPAN style=3D"FONT-WEIGHT: bold">From:=
</SPAN></B> "concurrency-interest-request at cs.oswego.edu" <concurrency-in=
terest-request at cs.oswego.edu><BR><B><SPAN style=3D"FONT-WEIGHT: bold">To=
:</SPAN></B> concurrency-interest at cs.oswego.edu <BR><B><SPAN style=3D"FONT-=
WEIGHT: bold">Sent:</SPAN></B> Monday, 16 April 2012 10:50 PM<BR><B><SPAN s=
tyle=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Concurrency-interest Digest,=
 Vol 87, Issue 27<BR></FONT></DIV><BR>Send Concurrency-interest mailing lis=
t submissions to<BR>    <A href=3D"mailto:concurrency-intere=
st at cs.oswego.edu"
 ymailto=3D"mailto:concurrency-interest at cs.oswego.edu">concurrency-interest=
@cs.oswego.edu</A><BR><BR>To subscribe or unsubscribe via the World Wide We=
b, visit<BR>    <A href=3D"http://cs.oswego.edu/mailman/list=
info/concurrency-interest" target=3D_blank>http://cs.oswego.edu/mailman/lis=
tinfo/concurrency-interest</A><BR>or, via email, send a message with subjec=
t or body 'help' to<BR>    <A href=3D"mailto:concurrency-int=
erest-request at cs.oswego.edu" ymailto=3D"mailto:concurrency-interest-request=
@cs.oswego.edu">concurrency-interest-request at cs.oswego.edu</A><BR><BR>You c=
an reach the person managing the list at<BR>    <A href=3D"m=
ailto:concurrency-interest-owner at cs.oswego.edu" ymailto=3D"mailto:concurren=
cy-interest-owner at cs.oswego.edu">concurrency-interest-owner at cs.oswego.edu</=
A><BR><BR>When replying, please edit your Subject line so it is more specif=
ic<BR>than "Re: Contents of Concurrency-interest digest..."<BR><BR><BR>Toda=
y's
 Topics:<BR><BR>  1. Re: CountedCompleters (Wolfgang Baltes)<BR> =
 2. Re: Java Deadlocks prevented (Boehm, Hans)<BR>  3. Re: Java Deadlo=
cks prevented (Nathan Reynolds)<BR>  4. Re: Concurrency-interest Diges=
t, Vol 87,    Issue 26 (Java<BR>      deadloc=
k prevented) (Rohit Kumar)<BR><BR><BR>-------------------------------------=
---------------------------------<BR><BR>Message: 1<BR>Date: Mon, 16 Apr 20=
12 18:01:50 +0200<BR>From: Wolfgang Baltes <<A href=3D"mailto:wolfgang.b=
altes at laposte.net" ymailto=3D"mailto:wolfgang.baltes at laposte.net">wolfgang.=
baltes at laposte.net</A>><BR>To: <A href=3D"mailto:concurrency-interest at cs=
.oswego.edu" ymailto=3D"mailto:concurrency-interest at cs.oswego.edu">concurre=
ncy-interest at cs.oswego.edu</A><BR>Subject: Re: [concurrency-interest] Count=
edCompleters<BR>Message-ID: <<A href=3D"mailto:4F8C426E.6090704 at laposte.=
net"
 ymailto=3D"mailto:4F8C426E.6090704 at laposte.net">4F8C426E.6090704 at laposte.n=
et</A>><BR>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflow=
ed<BR><BR>I apologize for a mistake in the last paragraph of my memo: using=
 <BR>quietlyJoinUnforked() in the SDK7 sample code for MergeSort does have =
a <BR>non-negligible performance impact (not no impact as stated). There is=
 <BR>better performance in case of recursions which produce many tasks that=
 <BR>are not explicitly forked, and it reduces the number of extra threads =
<BR>significantly, allowing larger problems to be solved with smaller memor=
y <BR>footprint.<BR><BR>Wolfgang.<BR><BR>On 2012-04-16 16:48, Wolfgang Balt=
es wrote:<BR>> Thanks, Doug, for a this addition to the FJ framework. I =
think that<BR>> CountedCompleter will address the needs of an entire cla=
ss of<BR>> applications in an efficient and simple to use manner.<BR>&gt=
;<BR>> I used the code and noticed that method doJoin() has become
 more<BR>> effective in avoiding blocking threads, and as a result fewer=
 extra<BR>> threads are created. I found the performance, compared to<BR=
>> RecursiveAction, to be equal or insignificantly different. This<BR>&g=
t; reduces the problem described in item 3 below.<BR>><BR>> However, =
at the same time, CountedCompleter does not fully satisfy the<BR>> needs=
 for a class of problems I work on. To this end, here are a few<BR>> enh=
ancements I would like to suggest:<BR>><BR>> 1: Symmetrically to onCo=
mpletion(), provide<BR>> onExceptionalCompletion(Throwable). This allows=
 filtering exception<BR>> propagation. There are cases where the propaga=
tion of the exception is<BR>> desired, and others where a corrective act=
ion is taken instead, such<BR>> as a retry.<BR>><BR>> 2: As a furt=
her enhancement to 1: enable any Throwable, including<BR>> checked excep=
tions. This allows the use of a CountedCompleter as a<BR>>
 CompletionHandler for asynchronous IO operations or as a wrapper for<BR>&g=
t; MethodHandles (which throw Throwable) without adding extra logic to<BR>&=
gt; capture and convert an IO exception. I read the documentation which<BR>=
> explains why this is currently limited to unchecked exceptions. While<=
BR>> I can agree with this in general, I feel the argument is weak for<B=
R>> CountedCompleter if it is there to support asynchronous tasks/events=
.<BR>> (May I add that using this type of framework is not for the<BR>&g=
t; faint-hearted anyway!?)<BR>><BR>> 3: Provide a method to join a ta=
sk that is not forked and/or not<BR>> completable, while minimizing work=
er thread blocking. For example,<BR>> CountedCompleter allows creating c=
hains of dependent tasks. Unless the<BR>> ultimate task (the last in the=
 chain) is forked/exists on the task<BR>> stack AND can complete because=
 all dependencies are resolved, joining<BR>> it will block the
 worker thread. I noticed (and my testing is limited<BR>> to a few test =
cases and therefore not representative) the blocking and<BR>> the creati=
on of other worker threads, ultimately running out of memory<BR>> or rea=
ching the thread count limit. If this task is not forked, then<BR>> join=
()/quietlyJoin() will block the worker thread. The following code<BR>> i=
s my (inexpert) attempt to provide a remedy. It is based on the<BR>> ass=
umption that a task that depends on others for completion is not<BR>> fo=
rked until all dependencies are resolved. For example, a<BR>> CountedCom=
pleter implementing CompletionHandler would fork itself<BR>> ("implicit =
fork") when the IO operation is done. This works very well<BR>> in my te=
st cases, but at this time I would not claim it to be<BR>> universally a=
pplicable or error free. It is shown here more to<BR>> demonstrate the a=
ttempt rather than as a reference implementation.<BR>> With
 access to private data structures, this can be done more<BR>> elegantly=
 and more reliably.<BR>><BR>>        static final=
 int RETRIES =3D 16;<BR>>        static final long W=
AIT_TIMEOUT =3D 1_000;    // Timeout in<BR>> microseconds.<BR>=
><BR>>        public final void quietlyJoinUnfork=
ed() {<BR>>            this.doJoinUnforked=
(false);<BR>>        }<BR>><BR>>    =
    public final void quietlyJoinUnforkedInterruptibly()<BR>>&=
nbsp;       throws InterruptedException {<BR>>  &nbs=
p;         if (this.doJoinUnforked(true)) {<BR>>&nbs=
p;               throw new InterruptedEx=
ception();<BR>>            }<BR>> =
       }<BR>><BR>>       
 public final boolean doJoinUnforked(final boolean<BR>> interruptibly) {=
<BR>>            int retries =3D RETRIES;<=
BR>>            boolean wasInterrupted =3D=
 false;<BR>>            while (!this.isDon=
e()) {<BR>>                ForkJ=
oinTask<?> t;<BR>>             =
   if ((t =3D pollTask()) !=3D null) {<BR>>      &nb=
sp;             t.quietlyInvoke();<BR>>&nb=
sp;                   if (t =
=3D=3D this) {<BR>>              &nbs=
p;         break;<BR>>        &n=
bsp;           }<BR>>      &nbsp=
;         }<BR>>          &=
nbsp;
     else {<BR>>            &nbs=
p;       if (retries-- > 0) {<BR>>     =
                   Thread.yiel=
d();<BR>>                  =
      continue;<BR>>          &n=
bsp;         }<BR>>        &nbsp=
;           wasInterrupted =3D Thread.interrupted(=
);<BR>>                  &n=
bsp; try {<BR>>                &=
nbsp;       // get(...) is used as a timed join(). It is<BR>=
> assumed that<BR>>              &=
nbsp;         // other code will perform get() on this =
task<BR>> to retrieve<BR>>         
               // the task's result or e=
xception.<BR>>                &n=
bsp;       this.get(WAIT_TIMEOUT, TimeUnit.MICROSECONDS);<BR=
>>                    =
    break;<BR>>            &nbsp=
;       }<BR>>            &=
nbsp;       catch (final InterruptedException consumed) {<BR=
>>                    =
    if (!interruptibly) {<BR>>        &nbs=
p;                   wasInterr=
upted =3D true;<BR>>              &nb=
sp;             continue;<BR>>  &nbsp=
;                  
   }<BR>>                &n=
bsp;       return true;<BR>>        &=
nbsp;           }<BR>>      &nbs=
p;             catch (final ExecutionExceptio=
n ignored) {<BR>>               =
         // See comment on get() above.<BR>>  &=
nbsp;                    =
 break;<BR>>                &nbs=
p;   }<BR>>                =
    catch (final TimeoutException ignored) {<BR>>   =
                     cont=
inue;<BR>>                 =
   }<BR>>             
   }<BR>>                re=
tries =3D RETRIES;<BR>>            }<BR>&g=
t;            if (wasInterrupted && !=
interruptibly) {<BR>>              &n=
bsp; Thread.currentThread().interrupt();<BR>>       =
         return false;<BR>>      &nbs=
p;     }<BR>>            return =
wasInterrupted;<BR>>        }<BR>><BR>> As alr=
eady mentioned this works quite well in a number of cases. For<BR>> exam=
ple, adding this method to the example MergeSort code and calling<BR>> q=
uietlyJoinUnforked(), results in the same overall performance,<BR>> redu=
ces the number of extra blocked worker threads to 1 if any<BR>> (instead=
 of up to 8 for the unmodified code; on a PC with 4<BR>>
 hyper-threading cores/8 threads), and allows for some extra<BR>> (recre=
ational?) freedom in joining the right and left sub-tasks in any<BR>> or=
der. It works in cases where no sub-task is forked explicitly. I<BR>> ob=
served that worker thread blocking only occurs towards the end of a<BR>>=
 large recursion, suggesting that worker threads only block - as<BR>> in=
tended - when there is no other work available (sometimes while<BR>> imp=
licit forking has not yet happened).<BR>><BR>> Wolfgang.<BR>><BR>&=
gt;<BR>><BR>> On 2012-04-09 16:16, Doug Lea wrote:<BR>>><BR>&gt=
;> After sitting on multiple variations for months, I committed<BR>>&=
gt; CountedCompleter, a completion-based flavor of ForkJoinTask.<BR>>&gt=
;<BR>>> As mentioned a few times over the past year, the main motivat=
ion<BR>>> is to better support tasks that perform IO or other base<BR=
>>> actions that may (or may not) take a lot of time to
 execute.<BR>>> As is the case with JDK7 async IO and other completio=
n-based<BR>>> frameworks, the most common path to efficiency is for s=
uch tasks<BR>>> to arrange continuation actions that occur upon their=
 completion.<BR>>> The main twist for CountedCompleters is that conti=
nuations<BR>>> might be dependent on multiple actions, not just one. =
(Or in<BR>>> other words, the continuations must be preceded by a spe=
cialized,<BR>>> "bottom-up" form of join.)<BR>>><BR>>> Th=
e CountedCompleter abstract class provides a minimal basis<BR>>> for =
these kinds of tasks. While some of the mechanics are<BR>>> reminisce=
nt of other FJ-like frameworks such as Intel TBB,<BR>>> CountedComple=
ters are designed to fit smoothly with other<BR>>> kinds of ForkJoinT=
asks (like RecursiveActions), and so still<BR>>> allow people to use =
the more pleasant Future-style conventions<BR>>> rather than
 count-based bottom-up joining unless they need them.<BR>>> At the sa=
me time, the CountedCompleter class exposes enough<BR>>> mechanics to=
 allow all sorts of tweaks that people can use<BR>>> to improve perfo=
rmance.<BR>>> In particular, in addition to usually being the best wa=
y to deal<BR>>> with IO etc bound tasks, CountedCompleters sometimes =
fare better<BR>>> than RecursiveActions in programs that entail lots =
of garbage<BR>>> collection because GC can have similar impact on tas=
k variability.<BR>>><BR>>> Even though targeted for JDK8, versi=
ons of CountedCompleter<BR>>> appear in the jsr166y and main reposito=
ries, not jsr166e. This is<BR>>> because they require a non-public ho=
ok into modified ForkJoinTask<BR>>> exception handling mechanics in o=
rder to properly propagate<BR>>> exceptional completions. For sources=
, docs, and jar files, see<BR>>> the usual links
 at<BR>>> <A href=3D"http://gee.cs.oswego.edu/dl/concurrency-interest=
/index.html" target=3D_blank>http://gee.cs.oswego.edu/dl/concurrency-intere=
st/index.html</A><BR>>><BR>>> The API docs include more details=
 and some examples:<BR>>> <A href=3D"http://gee.cs.oswego.edu/dl/jsr1=
66/dist/docs/java/util/concurrent/CountedCompleter.html" target=3D_blank>ht=
tp://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CountedComp=
leter.html</A><BR>>><BR>>><BR>>> I also added a few (with=
 more to come) test/demo programs that<BR>>> illustrate<BR>>> o=
ther usages. See CCBoxedLongSort and CCJacobi in<BR>>> <A href=3D"htt=
p://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/" target=3D=
_blank>http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/<=
/A><BR>>><BR>>> Please try these out. As always, comments and s=
uggestions<BR>>> (hopefully based on usage experience) would be
 welcome.<BR>>><BR>>> -Doug<BR>>><BR>>><BR>>>=
 _______________________________________________<BR>>> Concurrency-in=
terest mailing list<BR>>> <A href=3D"mailto:Concurrency-interest at cs.o=
swego.edu" ymailto=3D"mailto:Concurrency-interest at cs.oswego.edu">Concurrenc=
y-interest at cs.oswego.edu</A><BR>>> <A href=3D"http://cs.oswego.edu/ma=
ilman/listinfo/concurrency-interest" target=3D_blank>http://cs.oswego.edu/m=
ailman/listinfo/concurrency-interest</A><BR>>><BR>> ______________=
_________________________________<BR>> Concurrency-interest mailing list=
<BR>> <A href=3D"mailto:Concurrency-interest at cs.oswego.edu" ymailto=3D"m=
ailto:Concurrency-interest at cs.oswego.edu">Concurrency-interest at cs.oswego.ed=
u</A><BR>> <A href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-=
interest" target=3D_blank>http://cs.oswego.edu/mailman/listinfo/concurrency=
-interest</A><BR>><BR><BR><BR>------------------------------<BR><BR>Mess=
age:
 2<BR>Date: Mon, 16 Apr 2012 16:38:00 +0000<BR>From: "Boehm, Hans" <<A h=
ref=3D"mailto:hans.boehm at hp.com" ymailto=3D"mailto:hans.boehm at hp.com">hans.=
boehm at hp.com</A>><BR>To: Andrew Haley <<A href=3D"mailto:aph at redhat.c=
om" ymailto=3D"mailto:aph at redhat.com">aph at redhat.com</A>>,<BR> &nbs=
p;  "<A href=3D"mailto:concurrency-interest at cs.oswego.edu" ymailto=3D"=
mailto:concurrency-interest at cs.oswego.edu">concurrency-interest at cs.oswego.e=
du</A>"<BR>    <<A href=3D"mailto:concurrency-interest at cs=
.oswego.edu" ymailto=3D"mailto:concurrency-interest at cs.oswego.edu">concurre=
ncy-interest at cs.oswego.edu</A>><BR>Subject: Re: [concurrency-interest] J=
ava Deadlocks prevented<BR>Message-ID:<BR>    <<A href=3D=
"mailto:A3E67C2071F49C4CBC4F17E6D77CDDD235543F5B at G4W3299.americas.hpqcorp.n=
et"
 ymailto=3D"mailto:A3E67C2071F49C4CBC4F17E6D77CDDD235543F5B at G4W3299.america=
s.hpqcorp.net">A3E67C2071F49C4CBC4F17E6D77CDDD235543F5B at G4W3299.americas.hp=
qcorp.net</A>><BR>    <BR>Content-Type: text/plain; chars=
et=3D"us-ascii"<BR><BR>Important questions to consider when you write it up=
:<BR><BR>How does it compare to something like Gadara that uses whole progr=
am analysis and scheduling to avoid lock-based deadlocks?  (Hopefully =
it doesn't need whole program analysis.)  Other deadlock avoidance sch=
emes?<BR><BR>Once you detect a potential deadlock, how do you recover?&nbsp=
; Or can you always schedule so that the possibility doesn't arise?<BR><BR>=
Hans<BR><BR>> -----Original Message-----<BR>> From: <A href=3D"mailto=
:concurrency-interest-bounces at cs.oswego.edu" ymailto=3D"mailto:concurrency-=
interest-bounces at cs.oswego.edu">concurrency-interest-bounces at cs.oswego.edu<=
/A> [mailto:concurrency-<BR>> <A
 href=3D"mailto:interest-bounces at cs.oswego.edu" ymailto=3D"mailto:interest-=
bounces at cs.oswego.edu">interest-bounces at cs.oswego.edu</A>] On Behalf Of And=
rew Haley<BR>> Sent: Monday, April 16, 2012 4:34 AM<BR>> To: <A href=
=3D"mailto:concurrency-interest at cs.oswego.edu" ymailto=3D"mailto:concurrenc=
y-interest at cs.oswego.edu">concurrency-interest at cs.oswego.edu</A><BR>> Su=
bject: Re: [concurrency-interest] Java Deadlocks prevented<BR>> <BR>>=
 On 04/16/2012 12:06 PM, Rohit Kumar wrote:<BR>> <BR>> > I have fo=
und a way of preventing deadlocks in java. The<BR>> > methodology(whi=
ch is code) completely prevents the deadlock from<BR>> > occuring by =
detecting it in advance. This can be used across the<BR>> > systems s=
eamlessly.<BR>> ><BR>> > Kindly let me know what I need to do n=
ext. I want this to be part of<BR>> > next jdk release. I am writing =
this email as I have no idea what I<BR>> > need to do next to bring i=
t
 into limelight.<BR>> <BR>> Write it up, maybe present it to a confer=
ence, and wait for feedback.<BR>> That's how it always works.  If y=
our idea really works, people will<BR>> use it.<BR>> <BR>> Andrew.=
<BR>> _______________________________________________<BR>> Concurrenc=
y-interest mailing list<BR>> <A href=3D"mailto:Concurrency-interest at cs.o=
swego.edu" ymailto=3D"mailto:Concurrency-interest at cs.oswego.edu">Concurrenc=
y-interest at cs.oswego.edu</A><BR>> <A href=3D"http://cs.oswego.edu/mailma=
n/listinfo/concurrency-interest" target=3D_blank>http://cs.oswego.edu/mailm=
an/listinfo/concurrency-interest</A><BR><BR><BR><BR>-----------------------=
-------<BR><BR>Message: 3<BR>Date: Mon, 16 Apr 2012 10:11:00 -0700<BR>From:=
 Nathan Reynolds <<A href=3D"mailto:nathan.reynolds at oracle.com" ymailto=
=3D"mailto:nathan.reynolds at oracle.com">nathan.reynolds at oracle.com</A>><B=
R>To: "Boehm, Hans" <<A href=3D"mailto:hans.boehm at hp.com"
 ymailto=3D"mailto:hans.boehm at hp.com">hans.boehm at hp.com</A>><BR>Cc: "<A =
href=3D"mailto:concurrency-interest at cs.oswego.edu" ymailto=3D"mailto:concur=
rency-interest at cs.oswego.edu">concurrency-interest at cs.oswego.edu</A>"<BR>&n=
bsp;   <<A href=3D"mailto:concurrency-interest at cs.oswego.edu" =
ymailto=3D"mailto:concurrency-interest at cs.oswego.edu">concurrency-interest@=
cs.oswego.edu</A>><BR>Subject: Re: [concurrency-interest] Java Deadlocks=
 prevented<BR>Message-ID: <<A href=3D"mailto:4F8C52A4.70002 at oracle.com" =
ymailto=3D"mailto:4F8C52A4.70002 at oracle.com">4F8C52A4.70002 at oracle.com</A>&=
gt;<BR>Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed"<=
BR><BR>Deadlock prevention is very valuable.  It means deadlock prone =
code <BR>won't bring down a production server and cost the company millions=
 in <BR>down time.  It means consumers won't kill the process and requ=
est a refund.<BR><BR>How much does deadlock prevention cost?  Is the c=
ost on the
 thread that <BR>acquires locks or is it in a background thread?<BR><BR>Eac=
h time processors or systems increase the number of cores, I find we <BR>ha=
ve to do a round of lock contention fixing.  I have only seen 1 lock <=
BR>at a time be the bottleneck in the system.  Does deadlock preventio=
n <BR>increase the critical region of locks?  If so, this will definit=
ely <BR>reduce the scalability of the system if it impacts the 1 bottleneck=
ing lock.<BR><BR>Lock performance is a very important consideration.  =
Locks have evolved <BR>from fat locks (i.e trips into the OS kernel) to thi=
n locks (i.e. spin <BR>and CAS in user mode) to biased/lazy locks (i.e. no =
CAS and an <BR>indefinite lock owner).  All of this was done to reduce=
 the performance <BR>overhead of locks.  How does deadlock prevention =
impact the performance <BR>of biased, thin and fat locks?  I am not as=
 concerned about fat lock <BR>performance since most of the time the
 thread is going to block.<BR><BR>Nathan Reynolds <BR><<A href=3D"http:/=
/psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds" target=3D_blank>htt=
p://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds</A>> | <BR>Con=
sulting Member of Technical Staff | 602.333.9091<BR>Oracle PSR Engineering =
<<A href=3D"http://psr.us.oracle.com/" target=3D_blank>http://psr.us.ora=
cle.com/</A>> | Server Technology<BR><BR>On 4/16/2012 9:38 AM, Boehm, Ha=
ns wrote:<BR>> Important questions to consider when you write it up:<BR>=
><BR>> How does it compare to something like Gadara that uses whole p=
rogram analysis and scheduling to avoid lock-based deadlocks?  (Hopefu=
lly it doesn't need whole program analysis.)  Other deadlock avoidance=
 schemes?<BR>><BR>> Once you detect a potential deadlock, how do you =
recover?  Or can you always schedule so that the possibility doesn't a=
rise?<BR>><BR>> Hans<BR>><BR>>> -----Original
 Message-----<BR>>> From: <A href=3D"mailto:concurrency-interest-boun=
ces at cs.oswego.edu" ymailto=3D"mailto:concurrency-interest-bounces at cs.oswego=
.edu">concurrency-interest-bounces at cs.oswego.edu</A> [mailto:concurrency-<B=
R>>> <A href=3D"mailto:interest-bounces at cs.oswego.edu" ymailto=3D"mai=
lto:interest-bounces at cs.oswego.edu">interest-bounces at cs.oswego.edu</A>] On =
Behalf Of Andrew Haley<BR>>> Sent: Monday, April 16, 2012 4:34 AM<BR>=
>> To: <A href=3D"mailto:concurrency-interest at cs.oswego.edu" ymailto=
=3D"mailto:concurrency-interest at cs.oswego.edu">concurrency-interest at cs.oswe=
go.edu</A><BR>>> Subject: Re: [concurrency-interest] Java Deadlocks p=
revented<BR>>><BR>>> On 04/16/2012 12:06 PM, Rohit Kumar wrote:=
<BR>>><BR>>>> I have found a way of preventing deadlocks in =
java. The<BR>>>> methodology(which is code) completely prevents th=
e deadlock from<BR>>>> occuring by detecting it in advance. This c=
an be
 used across the<BR>>>> systems seamlessly.<BR>>>><BR>&gt=
;>> Kindly let me know what I need to do next. I want this to be part=
 of<BR>>>> next jdk release. I am writing this email as I have no =
idea what I<BR>>>> need to do next to bring it into limelight.<BR>=
>> Write it up, maybe present it to a conference, and wait for feedba=
ck.<BR>>> That's how it always works.  If your idea really works=
, people will<BR>>> use it.<BR>>><BR>>> Andrew.<BR>>&g=
t; _______________________________________________<BR>>> Concurrency-=
interest mailing list<BR>>> <A href=3D"mailto:Concurrency-interest at cs=
.oswego.edu" ymailto=3D"mailto:Concurrency-interest at cs.oswego.edu">Concurre=
ncy-interest at cs.oswego.edu</A><BR>>> <A href=3D"http://cs.oswego.edu/=
mailman/listinfo/concurrency-interest" target=3D_blank>http://cs.oswego.edu=
/mailman/listinfo/concurrency-interest</A><BR>>
 _______________________________________________<BR>> Concurrency-intere=
st mailing list<BR>> <A href=3D"mailto:Concurrency-interest at cs.oswego.ed=
u" ymailto=3D"mailto:Concurrency-interest at cs.oswego.edu">Concurrency-intere=
st at cs.oswego.edu</A><BR>> <A href=3D"http://cs.oswego.edu/mailman/listin=
fo/concurrency-interest" target=3D_blank>http://cs.oswego.edu/mailman/listi=
nfo/concurrency-interest</A><BR>-------------- next part --------------<BR>=
An HTML attachment was scrubbed...<BR>URL: <<A href=3D"http://cs.oswego.=
edu/pipermail/concurrency-interest/attachments/20120416/7ea89bb3/attachment=
-0001.html" target=3D_blank>http://cs.oswego.edu/pipermail/concurrency-inte=
rest/attachments/20120416/7ea89bb3/attachment-0001.html</A>><BR><BR>----=
--------------------------<BR><BR>Message: 4<BR>Date: Tue, 17 Apr 2012 01:2=
0:15 +0800 (SGT)<BR>From: Rohit Kumar <<A href=3D"mailto:rohitk242 at yahoo=
.co.in"
 ymailto=3D"mailto:rohitk242 at yahoo.co.in">rohitk242 at yahoo.co.in</A>><BR>=
To: "<A href=3D"mailto:concurrency-interest at cs.oswego.edu" ymailto=3D"mailt=
o:concurrency-interest at cs.oswego.edu">concurrency-interest at cs.oswego.edu</A=
>"<BR>    <<A href=3D"mailto:concurrency-interest at cs.oswe=
go.edu" ymailto=3D"mailto:concurrency-interest at cs.oswego.edu">concurrency-i=
nterest at cs.oswego.edu</A>><BR>Subject: Re: [concurrency-interest] Concur=
rency-interest Digest, Vol<BR>    87,    Issu=
e 26 (Java deadlock prevented)<BR>Message-ID:<BR>    <<A =
href=3D"mailto:1334596815.27848.YahooMailNeo at web193403.mail.sg3.yahoo.com" =
ymailto=3D"mailto:1334596815.27848.YahooMailNeo at web193403.mail.sg3.yahoo.co=
m">1334596815.27848.YahooMailNeo at web193403.mail.sg3.yahoo.com</A>><BR>Co=
ntent-Type: text/plain; charset=3D"iso-8859-1"<BR><BR>Andrew:<BR>?<BR>Thank=
s for the reply. Can you kindly let me know where do I need to present it ?=
 Where
 will the conference be held ? Can I present it online or I have to come in=
 person ?<BR>?<BR>Waiting for your early reply once again.<BR>?<BR>Thanks &=
amp; Regards,<BR>Rohit Kumar<BR><BR>From: "<A href=3D"mailto:concurrency-in=
terest-request at cs.oswego.edu" ymailto=3D"mailto:concurrency-interest-reques=
t at cs.oswego.edu">concurrency-interest-request at cs.oswego.edu</A>" <<A hre=
f=3D"mailto:concurrency-interest-request at cs.oswego.edu" ymailto=3D"mailto:c=
oncurrency-interest-request at cs.oswego.edu">concurrency-interest-request at cs.=
oswego.edu</A>><BR>To: <A href=3D"mailto:concurrency-interest at cs.oswego.=
edu" ymailto=3D"mailto:concurrency-interest at cs.oswego.edu">concurrency-inte=
rest at cs.oswego.edu</A> <BR>Sent: Monday, 16 April 2012 9:30 PM<BR>Subject: =
Concurrency-interest Digest, Vol 87, Issue 26<BR><BR>Send Concurrency-inter=
est mailing list submissions to<BR>??? <A href=3D"mailto:concurrency-intere=
st at cs.oswego.edu"
 ymailto=3D"mailto:concurrency-interest at cs.oswego.edu">concurrency-interest=
@cs.oswego.edu</A><BR><BR>To subscribe or unsubscribe via the World Wide We=
b, visit<BR>??? <A href=3D"http://cs.oswego.edu/mailman/listinfo/concurrenc=
y-interest" target=3D_blank>http://cs.oswego.edu/mailman/listinfo/concurren=
cy-interest</A><BR>or, via email, send a message with subject or body 'help=
' to<BR>??? <A href=3D"mailto:concurrency-interest-request at cs.oswego.edu" y=
mailto=3D"mailto:concurrency-interest-request at cs.oswego.edu">concurrency-in=
terest-request at cs.oswego.edu</A><BR><BR>You can reach the person managing t=
he list at<BR>??? <A href=3D"mailto:concurrency-interest-owner at cs.oswego.ed=
u" ymailto=3D"mailto:concurrency-interest-owner at cs.oswego.edu">concurrency-=
interest-owner at cs.oswego.edu</A><BR><BR>When replying, please edit your Sub=
ject line so it is more specific<BR>than "Re: Contents of Concurrency-inter=
est digest..."<BR><BR><BR>Today's Topics:<BR><BR>? 1. (no subject) (Rohit
 Kumar)<BR>? 2. Java Deadlocks prevented (Rohit Kumar)<BR>? 3. Re: Java Dea=
dlocks prevented (Andrew Haley)<BR>? 4. Re: CountedCompleters (Wolfgang Bal=
tes)<BR><BR><BR>-----------------------------------------------------------=
-----------<BR><BR>Message: 1<BR>Date: Mon, 16 Apr 2012 19:03:59 +0800 (SGT=
)<BR>From: Rohit Kumar <<A href=3D"mailto:rohitk242 at yahoo.co.in" ymailto=
=3D"mailto:rohitk242 at yahoo.co.in">rohitk242 at yahoo.co.in</A>><BR>To: "<A =
href=3D"mailto:concurrency-interest at cs.oswego.edu" ymailto=3D"mailto:concur=
rency-interest at cs.oswego.edu">concurrency-interest at cs.oswego.edu</A>"<BR>??=
? <<A href=3D"mailto:concurrency-interest at cs.oswego.edu" ymailto=3D"mail=
to:concurrency-interest at cs.oswego.edu">concurrency-interest at cs.oswego.edu</=
A>><BR>Cc: "<A href=3D"mailto:concurrency-interest-owner at cs.oswego.edu" =
ymailto=3D"mailto:concurrency-interest-owner at cs.oswego.edu">concurrency-int=
erest-owner at cs.oswego.edu</A>"<BR>??? <<A
 href=3D"mailto:concurrency-interest-owner at cs.oswego.edu" ymailto=3D"mailto=
:concurrency-interest-owner at cs.oswego.edu">concurrency-interest-owner at cs.os=
wego.edu</A>><BR>Subject: [concurrency-interest] (no subject)<BR>Message=
-ID:<BR>??? <<A href=3D"mailto:1334574239.81244.YahooMailNeo at web193402.m=
ail.sg3.yahoo.com" ymailto=3D"mailto:1334574239.81244.YahooMailNeo at web19340=
2.mail.sg3.yahoo.com">1334574239.81244.YahooMailNeo at web193402.mail.sg3.yaho=
o.com</A>><BR>Content-Type: text/plain; charset=3D"iso-8859-1"<BR><BR>Hi=
 All,<BR>?<BR>I have found a way of preventing deadlocks in java. The metho=
dology(which is code) completely prevents the deadlock from accuring by det=
ecting it in advance. This can be used across the systems seamlessly. <BR>?=
<BR>Kindly let me know what I need to do next. I want this to be part of ne=
xt jdk release.<BR>?<BR>Thanks & Regards,<BR>Rohit Kumar<BR>-----------=
--- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL:
 <<A href=3D"http://cs.oswego.edu/pipermail/concurrency-interest/attachm=
ents/20120416/a6588341/attachment-0001.html" target=3D_blank>http://cs.oswe=
go.edu/pipermail/concurrency-interest/attachments/20120416/a6588341/attachm=
ent-0001.html</A>><BR><BR>------------------------------<BR><BR>Message:=
 2<BR>Date: Mon, 16 Apr 2012 19:06:22 +0800 (SGT)<BR>From: Rohit Kumar <=
<A href=3D"mailto:rohitk242 at yahoo.co.in" ymailto=3D"mailto:rohitk242 at yahoo.=
co.in">rohitk242 at yahoo.co.in</A>><BR>To: "<A href=3D"mailto:concurrency-=
interest at cs.oswego.edu" ymailto=3D"mailto:concurrency-interest at cs.oswego.ed=
u">concurrency-interest at cs.oswego.edu</A>"<BR>??? <<A href=3D"mailto:con=
currency-interest at cs.oswego.edu" ymailto=3D"mailto:concurrency-interest at cs.=
oswego.edu">concurrency-interest at cs.oswego.edu</A>><BR>Cc: "<A href=3D"m=
ailto:concurrency-interest-owner at cs.oswego.edu" ymailto=3D"mailto:concurren=
cy-interest-owner at cs.oswego.edu">concurrency-interest-owner at cs.oswego.edu</=
A>"<BR>???
 <<A href=3D"mailto:concurrency-interest-owner at cs.oswego.edu" ymailto=3D=
"mailto:concurrency-interest-owner at cs.oswego.edu">concurrency-interest-owne=
r at cs.oswego.edu</A>><BR>Subject: [concurrency-interest] Java Deadlocks p=
revented<BR>Message-ID:<BR>??? <<A href=3D"mailto:1334574382.90584.Yahoo=
MailNeo at web193403.mail.sg3.yahoo.com" ymailto=3D"mailto:1334574382.90584.Ya=
hooMailNeo at web193403.mail.sg3.yahoo.com">1334574382.90584.YahooMailNeo at web1=
93403.mail.sg3.yahoo.com</A>><BR>Content-Type: text/plain; charset=3D"ut=
f-8"<BR><BR><BR><BR>Hi All,<BR><BR>I have found a way of preventing deadloc=
ks in java. The methodology(which is code) completely prevents the deadlock=
 from occuring by detecting it in advance. This can be used across the syst=
ems seamlessly. <BR><BR>Kindly let me know what I need to do next. I want t=
his to be part of next jdk release. I am writing this email as I have no id=
ea what I need to do next to bring it into limelight.<BR><BR>Thanks &
 Regards,<BR>Rohit Kumar<BR>-------------- next part --------------<BR>An H=
TML attachment was scrubbed...<BR>URL: <<A href=3D"http://cs.oswego.edu/=
pipermail/concurrency-interest/attachments/20120416/064a4873/attachment-000=
1.html" target=3D_blank>http://cs.oswego.edu/pipermail/concurrency-interest=
/attachments/20120416/064a4873/attachment-0001.html</A>><BR><BR>--------=
----------------------<BR><BR>Message: 3<BR>Date: Mon, 16 Apr 2012 12:33:45=
 +0100<BR>From: Andrew Haley <<A href=3D"mailto:aph at redhat.com" ymailto=
=3D"mailto:aph at redhat.com">aph at redhat.com</A>><BR>To: <A href=3D"mailto:=
concurrency-interest at cs.oswego.edu" ymailto=3D"mailto:concurrency-interest@=
cs.oswego.edu">concurrency-interest at cs.oswego.edu</A><BR>Subject: Re: [conc=
urrency-interest] Java Deadlocks prevented<BR>Message-ID: <<A href=3D"ma=
ilto:4F8C0399.8040301 at redhat.com" ymailto=3D"mailto:4F8C0399.8040301 at redhat=
.com">4F8C0399.8040301 at redhat.com</A>><BR>Content-Type: text/plain;
 charset=3DISO-8859-1<BR><BR>On 04/16/2012 12:06 PM, Rohit Kumar wrote:<BR>=
<BR>> I have found a way of preventing deadlocks in java. The<BR>> me=
thodology(which is code) completely prevents the deadlock from<BR>> occu=
ring by detecting it in advance. This can be used across the<BR>> system=
s seamlessly.<BR>> <BR>> Kindly let me know what I need to do next. I=
 want this to be part of<BR>> next jdk release. I am writing this email =
as I have no idea what I<BR>> need to do next to bring it into limelight=
.<BR><BR>Write it up, maybe present it to a conference, and wait for feedba=
ck.<BR>That's how it always works.? If your idea really works, people will<=
BR>use it.<BR><BR>Andrew.<BR><BR><BR>------------------------------<BR><BR>=
Message: 4<BR>Date: Mon, 16 Apr 2012 16:48:31 +0200<BR>From: Wolfgang Balte=
s <<A href=3D"mailto:wolfgang.baltes at laposte.net" ymailto=3D"mailto:wolf=
gang.baltes at laposte.net">wolfgang.baltes at laposte.net</A>><BR>To: "<A
 href=3D"mailto:Concurrency-interest at cs.oswego.edu" ymailto=3D"mailto:Concu=
rrency-interest at cs.oswego.edu">Concurrency-interest at cs.oswego.edu</A>"<BR>?=
?? <<A href=3D"mailto:Concurrency-interest at cs.oswego.edu" ymailto=3D"mai=
lto:Concurrency-interest at cs.oswego.edu">Concurrency-interest at cs.oswego.edu<=
/A>><BR>Subject: Re: [concurrency-interest] CountedCompleters<BR>Message=
-ID: <<A href=3D"mailto:4F8C313F.2080308 at laposte.net" ymailto=3D"mailto:=
4F8C313F.2080308 at laposte.net">4F8C313F.2080308 at laposte.net</A>><BR>Conte=
nt-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed<BR><BR>Thanks, D=
oug, for a this addition to the FJ framework. I think that <BR>CountedCompl=
eter will address the needs of an entire class of <BR>applications in an ef=
ficient and simple to use manner.<BR><BR>I used the code and noticed that m=
ethod doJoin() has become more <BR>effective in avoiding blocking threads, =
and as a result fewer extra <BR>threads are created. I found the performanc=
e,
 compared to <BR>RecursiveAction, to be equal or insignificantly different.=
 This reduces <BR>the problem described in item 3 below.<BR><BR>However, at=
 the same time, CountedCompleter does not fully satisfy the <BR>needs for a=
 class of problems I work on. To this end, here are a few <BR>enhancements =
I would like to suggest:<BR><BR>1: Symmetrically to onCompletion(), provide=
 <BR>onExceptionalCompletion(Throwable). This allows filtering exception <B=
R>propagation. There are cases where the propagation of the exception is <B=
R>desired, and others where a corrective action is taken instead, such as <=
BR>a retry.<BR><BR>2: As a further enhancement to 1: enable any Throwable, =
including <BR>checked exceptions. This allows the use of a CountedCompleter=
 as a <BR>CompletionHandler for asynchronous IO operations or as a wrapper =
for <BR>MethodHandles (which throw Throwable) without adding extra logic to=
 <BR>capture and convert an IO exception. I read the documentation
 which <BR>explains why this is currently limited to unchecked exceptions. =
While I <BR>can agree with this in general, I feel the argument is weak for=
 <BR>CountedCompleter if it is there to support asynchronous tasks/events. =
<BR>(May I add that using this type of framework is not for the <BR>faint-h=
earted anyway!?)<BR><BR>3: Provide a method to join a task that is not fork=
ed and/or not <BR>completable, while minimizing worker thread blocking. For=
 example, <BR>CountedCompleter allows creating chains of dependent tasks. U=
nless the <BR>ultimate task (the last in the chain) is forked/exists on the=
 task stack <BR>AND can complete because all dependencies are resolved, joi=
ning it will <BR>block the worker thread. I noticed (and my testing is limi=
ted to a few <BR>test cases and therefore not representative) the blocking =
and the <BR>creation of other worker threads, ultimately running out of mem=
ory or <BR>reaching the thread count limit. If this task is not
 forked, then <BR>join()/quietlyJoin() will block the worker thread. The fo=
llowing code is <BR>my (inexpert) attempt to provide a remedy. It is based =
on the assumption <BR>that a task that depends on others for completion is =
not forked until <BR>all dependencies are resolved. For example, a CountedC=
ompleter <BR>implementing CompletionHandler would fork itself ("implicit fo=
rk") when <BR>the IO operation is done. This works very well in my test cas=
es, but at <BR>this time I would not claim it to be universally applicable =
or error <BR>free. It is shown here more to demonstrate the attempt rather =
than as a <BR>reference implementation. With access to private data structu=
res, this <BR>can be done more elegantly and more reliably.<BR><BR>? ? ? ? =
static final int RETRIES =3D 16;<BR>? ? ? ? static final long WAIT_TIMEOUT =
=3D 1_000;? ? // Timeout in <BR>microseconds.<BR><BR>? ? ? ? public final v=
oid quietlyJoinUnforked() {<BR>? ? ? ? ? ?
 this.doJoinUnforked(false);<BR>? ? ? ? }<BR><BR>? ? ? ? public final void =
quietlyJoinUnforkedInterruptibly()<BR>? ? ? ? throws InterruptedException {=
<BR>? ? ? ? ? ? if (this.doJoinUnforked(true)) {<BR>? ? ? ? ? ? ? ? throw n=
ew InterruptedException();<BR>? ? ? ? ? ? }<BR>? ? ? ? }<BR><BR>? ? ? ? pub=
lic final boolean doJoinUnforked(final boolean interruptibly) {<BR>? ? ? ? =
? ? int retries =3D RETRIES;<BR>? ? ? ? ? ? boolean wasInterrupted =3D fals=
e;<BR>? ? ? ? ? ? while (!this.isDone()) {<BR>? ? ? ? ? ? ? ? ForkJoinTask&=
lt;?> t;<BR>? ? ? ? ? ? ? ? if ((t =3D pollTask()) !=3D null) {<BR>? ? ?=
 ? ? ? ? ? ? ? t.quietlyInvoke();<BR>? ? ? ? ? ? ? ? ? ? if (t =3D=3D this)=
 {<BR>? ? ? ? ? ? ? ? ? ? ? ? break;<BR>? ? ? ? ? ? ? ? ? ? }<BR>? ? ? ? ? =
? ? ? }<BR>? ? ? ? ? ? ? ? else {<BR>? ? ? ? ? ? ? ? ? ? if (retries-- >=
 0) {<BR>? ? ? ? ? ? ? ? ? ? ? ? Thread.yield();<BR>? ? ? ? ? ? ? ? ? ? ? ?=
 continue;<BR>? ? ? ? ? ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? ? ? wasInterrupted =
=3D
 Thread.interrupted();<BR>? ? ? ? ? ? ? ? ? ? try {<BR>? ? ? ? ? ? ? ? ? ? =
? ? // get(...) is used as a timed join(). It is <BR>assumed that<BR>? ? ? =
? ? ? ? ? ? ? ? ? // other code will perform get() on this task <BR>to retr=
ieve<BR>? ? ? ? ? ? ? ? ? ? ? ? // the task's result or exception.<BR>? ? ?=
 ? ? ? ? ? ? ? ? ? this.get(WAIT_TIMEOUT, TimeUnit.MICROSECONDS);<BR>? ? ? =
? ? ? ? ? ? ? ? ? break;<BR>? ? ? ? ? ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? ? ? ca=
tch (final InterruptedException consumed) {<BR>? ? ? ? ? ? ? ? ? ? ? ? if (=
!interruptibly) {<BR>? ? ? ? ? ? ? ? ? ? ? ? ? ? wasInterrupted =3D true;<B=
R>? ? ? ? ? ? ? ? ? ? ? ? ? ? continue;<BR>? ? ? ? ? ? ? ? ? ? ? ? }<BR>? ?=
 ? ? ? ? ? ? ? ? ? ? return true;<BR>? ? ? ? ? ? ? ? ? ? }<BR>? ? ? ? ? ? ?=
 ? ? ? catch (final ExecutionException ignored) {<BR>? ? ? ? ? ? ? ? ? ? ? =
? // See comment on get() above.<BR>? ? ? ? ? ? ? ? ? ? ? ? break;<BR>? ? ?=
 ? ? ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? ? ? catch (final TimeoutException
 ignored) {<BR>? ? ? ? ? ? ? ? ? ? ? ? continue;<BR>? ? ? ? ? ? ? ? ? ? }<B=
R>? ? ? ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? retries =3D RETRIES;<BR>? ? ? ? ? ? =
}<BR>? ? ? ? ? ? if (wasInterrupted && !interruptibly) {<BR>? ? ? ?=
 ? ? ? ? Thread.currentThread().interrupt();<BR>? ? ? ? ? ? ? ? return fals=
e;<BR>? ? ? ? ? ? }<BR>? ? ? ? ? ? return wasInterrupted;<BR>? ? ? ? }<BR><=
BR>As already mentioned this works quite well in a number of cases. For <BR=
>example, adding this method to the example MergeSort code and calling <BR>=
quietlyJoinUnforked(), results in the same overall performance, reduces <BR=
>the number of extra blocked worker threads to 1 if any (instead of up to <=
BR>8 for the unmodified code; on a PC with 4 hyper-threading cores/8 <BR>th=
reads), and allows for some extra (recreational?) freedom in joining <BR>th=
e right and left sub-tasks in any order. It works in cases where no <BR>sub=
-task is forked explicitly. I observed that worker thread blocking
 <BR>only occurs towards the end of a large recursion, suggesting that work=
er <BR>threads only block - as intended - when there is no other work avail=
able <BR>(sometimes while implicit forking has not yet happened).<BR><BR>Wo=
lfgang.<BR><BR><BR><BR>On 2012-04-09 16:16, Doug Lea wrote:<BR>><BR>>=
 After sitting on multiple variations for months, I committed<BR>> Count=
edCompleter, a completion-based flavor of ForkJoinTask.<BR>><BR>> As =
mentioned a few times over the past year, the main motivation<BR>> is to=
 better support tasks that perform IO or other base<BR>> actions that ma=
y (or may not) take a lot of time to execute.<BR>> As is the case with J=
DK7 async IO and other completion-based<BR>> frameworks, the most common=
 path to efficiency is for such tasks<BR>> to arrange continuation actio=
ns that occur upon their completion.<BR>> The main twist for CountedComp=
leters is that continuations<BR>> might be dependent on multiple
 actions, not just one. (Or in<BR>> other words, the continuations must =
be preceded by a specialized,<BR>> "bottom-up" form of join.)<BR>><BR=
>> The CountedCompleter abstract class provides a minimal basis<BR>> =
for these kinds of tasks. While some of the mechanics are<BR>> reminisce=
nt of other FJ-like frameworks such as Intel TBB,<BR>> CountedCompleters=
 are designed to fit smoothly with other<BR>> kinds of ForkJoinTasks (li=
ke RecursiveActions), and so still<BR>> allow people to use the more ple=
asant Future-style conventions<BR>> rather than count-based bottom-up jo=
ining unless they need them.<BR>> At the same time, the CountedCompleter=
 class exposes enough<BR>> mechanics to allow all sorts of tweaks that p=
eople can use<BR>> to improve performance.<BR>> In particular, in add=
ition to usually being the best way to deal<BR>> with IO etc bound tasks=
, CountedCompleters sometimes fare better<BR>> than
 RecursiveActions in programs that entail lots of garbage<BR>> collectio=
n because GC can have similar impact on task variability.<BR>><BR>> E=
ven though targeted for JDK8, versions of CountedCompleter<BR>> appear i=
n the jsr166y and main repositories, not jsr166e. This is<BR>> because t=
hey require a non-public hook into modified ForkJoinTask<BR>> exception =
handling mechanics in order to properly propagate<BR>> exceptional compl=
etions. For sources, docs, and jar files, see<BR>> the usual links at <B=
R>> <A href=3D"http://gee.cs.oswego.edu/dl/concurrency-interest/index.ht=
ml" target=3D_blank>http://gee.cs.oswego.edu/dl/concurrency-interest/index.=
html</A><BR>><BR>> The API docs include more details and some example=
s:<BR>> <A href=3D"http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/uti=
l/concurrent/CountedCompleter.html" target=3D_blank>http://gee.cs.oswego.ed=
u/dl/jsr166/dist/docs/java/util/concurrent/CountedCompleter.html</A>
 <BR>><BR>><BR>> I also added a few (with more to come) test/demo =
programs that illustrate<BR>> other usages. See CCBoxedLongSort and CCJa=
cobi in<BR>> <A href=3D"http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr=
166/src/test/loops/" target=3D_blank>http://gee.cs.oswego.edu/cgi-bin/viewc=
vs.cgi/jsr166/src/test/loops/</A><BR>><BR>> Please try these out. As =
always, comments and suggestions<BR>> (hopefully based on usage experien=
ce) would be welcome.<BR>><BR>> -Doug<BR>><BR>><BR>> _______=
________________________________________<BR>> Concurrency-interest maili=
ng list<BR>> <A href=3D"mailto:Concurrency-interest at cs.oswego.edu" ymail=
to=3D"mailto:Concurrency-interest at cs.oswego.edu">Concurrency-interest at cs.os=
wego.edu</A><BR>> <A href=3D"http://cs.oswego.edu/mailman/listinfo/concu=
rrency-interest"
 target=3D_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest=
</A><BR>><BR><BR><BR>------------------------------<BR><BR>_____________=
__________________________________<BR>Concurrency-interest mailing list<BR>=
<A href=3D"mailto:Concurrency-interest at cs.oswego.edu" ymailto=3D"mailto:Con=
currency-interest at cs.oswego.edu">Concurrency-interest at cs.oswego.edu</A><BR>=
<A href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" targ=
et=3D_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><=
BR><BR><BR>End of Concurrency-interest Digest, Vol 87, Issue 26<BR>********=
********************************************<BR>-------------- next part --=
------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href=3D"h=
ttp://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120417/757=
46dcb/attachment.html"
 target=3D_blank>http://cs.oswego.edu/pipermail/concurrency-interest/attach=
ments/20120417/75746dcb/attachment.html</A>><BR><BR>--------------------=
----------<BR><BR>_______________________________________________<BR>Concur=
rency-interest mailing list<BR><A href=3D"mailto:Concurrency-interest at cs.os=
wego.edu" ymailto=3D"mailto:Concurrency-interest at cs.oswego.edu">Concurrency=
-interest at cs.oswego.edu</A><BR><A href=3D"http://cs.oswego.edu/mailman/list=
info/concurrency-interest" target=3D_blank>http://cs.oswego.edu/mailman/lis=
tinfo/concurrency-interest</A><BR><BR><BR>End of Concurrency-interest Diges=
t, Vol 87, Issue 27<BR>****************************************************=
<BR><BR><BR></DIV></DIV></div></body></html>
--897404883-1652871492-1334601360=:99294--

--===============0377691237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0377691237==--


More information about the Concurrency-interest mailing list