<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19190"></HEAD>
<BODY>
<DIV><SPAN class=562223822-16042012><FONT color=#0000ff size=2 face=Arial>(Fixed 
subject line: everyone - please don't reply to a digest and so screw up the 
subject!)</FONT></SPAN></DIV>
<DIV><SPAN class=562223822-16042012><FONT color=#0000ff size=2 
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=562223822-16042012><FONT color=#0000ff size=2 face=Arial>I hate 
to be a wet blanket but really this is nothing new. Deadlock detection and 
prevention is as old as deadlock. Throwing an exception when you are potentially 
going to deadlock avoids the deadlock but doesn't necessarily imply that any 
corrective action is possible at runtime - you would need to employ 
transactional semantics to undo nested state changes, and all of your code would 
need to know about the rest to know how the locking is related and so may be 
done a different way. Such mechanisms can be useful development tools, but 
static analysis can be better at identifying potential deadlocks, than runtime 
checks that require the right timing for the deadlock to be encountered. There's 
decades of literature on this.</FONT></SPAN></DIV>
<DIV><SPAN class=562223822-16042012><FONT color=#0000ff size=2 
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=562223822-16042012><FONT color=#0000ff size=2 face=Arial>David 
Holmes</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px" 
dir=ltr>
  <DIV dir=ltr class=OutlookMessageHeader align=left><FONT size=2 
  face=Tahoma>-----Original Message-----<BR><B>From:</B> 
  concurrency-interest-bounces@cs.oswego.edu 
  [mailto:concurrency-interest-bounces@cs.oswego.edu]<B>On Behalf Of </B>Rohit 
  Kumar<BR><B>Sent:</B> Tuesday, 17 April 2012 5:45 AM<BR><B>To:</B> Nathan 
  Reynolds; sandeep.bansal85@gmail.com; khilan@doc.ic.ac.uk<BR><B>Cc:</B> 
  concurrency-interest@cs.oswego.edu<BR><B>Subject:</B> Re: 
  [concurrency-interest] Concurrency-interest Digest, Vol 87,Issue 
  27<BR><BR></FONT></DIV>
  <DIV 
  style="BACKGROUND-COLOR: #fff; FONT-FAMILY: times new roman, new york, times, serif; COLOR: #000; FONT-SIZE: 12pt">
  <DIV style="RIGHT: auto"><SPAN style="RIGHT: auto">The whole idea that I 
  wanted to bring up is that use of synchronized keyword (implicit locks) can 
  make your program vulnerable to deadlocks as you have no control over 
  acquisition of locks. Once you use explicit locks as provided by java 
  concurrent apis, deadlocks can be prevented completely. And yes, my program 
  uses synchronized keywords, but all in one place and is completely and 
  thoroughly tested. Usage of synchronized keyword should be 
  confined.</SPAN></DIV>
  <DIV style="RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN> </DIV>
  <DIV style="RIGHT: auto"><SPAN style="RIGHT: auto">My program detects cycles 
  in lock-acquisition graph. The overhead will be proportional to all the 
  threads that are holding locks but not yet released <VAR 
  id=yui-ie-cursor></VAR>and this is not great compared to restarting the server 
  everytime the deadlock happens.</SPAN></DIV>
  <DIV style="RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN> </DIV>
  <DIV style="RIGHT: auto"><SPAN style="RIGHT: auto">I will see if I can present 
  it to any java forum. This is written in java but the concept can be applied 
  in any programming language.</SPAN></DIV>
  <DIV style="RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN> </DIV>
  <DIV style="RIGHT: auto"><SPAN style="RIGHT: auto">Thanks & 
  Regards,</SPAN></DIV>
  <DIV style="RIGHT: auto"><SPAN style="RIGHT: auto">Rohit Kumar</SPAN></DIV>
  <DIV><BR></DIV>
  <DIV 
  style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">
  <DIV 
  style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">
  <DIV style="RIGHT: auto" dir=ltr><FONT size=2 face=Arial>
  <DIV 
  style="BORDER-BOTTOM: #ccc 1px solid; BORDER-LEFT: #ccc 1px solid; PADDING-BOTTOM: 0px; LINE-HEIGHT: 0; MARGIN: 5px 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; HEIGHT: 0px; FONT-SIZE: 0px; BORDER-TOP: #ccc 1px solid; BORDER-RIGHT: #ccc 1px solid; PADDING-TOP: 0px" 
  class=hr contentEditable=false readonly="true"></DIV><B><SPAN 
  style="FONT-WEIGHT: bold">From:</SPAN></B> Nathan Reynolds 
  <nathan.reynolds@oracle.com><BR><B><SPAN 
  style="FONT-WEIGHT: bold">To:</SPAN></B> Rohit Kumar 
  <rohitk242@yahoo.co.in> <BR><B><SPAN 
  style="FONT-WEIGHT: bold">Cc:</SPAN></B> "concurrency-interest@cs.oswego.edu" 
  <concurrency-interest@cs.oswego.edu> <BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, 17 April 2012 12:52 
  AM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: 
  [concurrency-interest] Concurrency-interest Digest, Vol 87, Issue 
  27<BR></FONT></DIV><BR>
  <META content=off http-equiv=x-dns-prefetch-control>
  <DIV style="RIGHT: auto" id=yiv1757882316>
  <DIV style="RIGHT: auto">Synchronized blocks are used every where.  You 
  could use ASM (<A class=yiv1757882316moz-txt-link-freetext 
  href="http://asm.ow2.org/" rel=nofollow target=_blank>http://asm.ow2.org/</A>) 
  to instrument all synchronized blocks (i.e. monitorenter and monitorexit 
  bytecodes).  Simply put a call to your deadlock-check just before the 
  monitorenter instruction.  You could also use this to inject your code 
  into all Locks.<BR><BR>If you want to avoid the overhead during lock 
  acquisition, you could have a background thread detect the deadlock and then 
  make one thread involved in the deadlock throw an exception using 
  Thread.stop(Throwable).  Thread.stop() is a misnomer in my opinion.  
  It doesn't stop the thread immediately.  Instead, it causes the thread to 
  throw an exception which unwinds the stack and if not caught causes the thread 
  to terminate.  It is deprecated because the exception can be thrown at 
  any point during the execution of the thread and this makes it very hard to 
  get it bug free.  (It might be deprecated for other reasons as 
  well.)  However, if you know that the threads are indefinitely 
  deadlocked, then the thread won't wake up any time and I naively don't see why 
  using Thread.stop(Throwable) would be a problem.  (Note: I am not sure if 
  Thread.stop() will throw an exception while the thread is blocked inside 
  monitorenter).<BR><BR>> <SPAN>Finally where do I need to present this 
  writeup?</SPAN><BR><BR>I have never presented anything outside of Oracle Open 
  World.  I have attended Java One.  Sorry, I can't be of much 
  help.  Since this is Java code, you might consider presenting at Java 
  One.  I am not sure if that is appropriate venue, though.<BR><BR>
  <DIV class=yiv1757882316moz-signature><A 
  href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds" 
  rel=nofollow target=_blank>Nathan Reynolds</A> | Consulting Member of 
  Technical Staff | 602.333.9091<BR><FONT color=red>Oracle</FONT> <A 
  href="http://psr.us.oracle.com/" rel=nofollow target=_blank>PSR 
  Engineering</A> | Server Technology<BR></DIV><BR>On 4/16/2012 11:36 AM, Rohit 
  Kumar wrote: 
  <BLOCKQUOTE type="cite">
    <DIV 
    style="BACKGROUND-COLOR: #fff; FONT-FAMILY: times new roman, new york, times, serif; COLOR: #000; FONT-SIZE: 12pt">
    <DIV><SPAN>Hans,Nathan,</SPAN></DIV>
    <DIV><SPAN></SPAN> </DIV>
    <DIV><SPAN>I am not aware of anything like Gadara yet. My implementation 
    assumes that there are no synchnonized keywords (implicit locks) in 
    your program. It requires you to use explicit locks (e.g. Lock class in java 
    concurrent api). There is no background thread running here. The 
    deadlock-check happens at each lock acquisition request; it runs an 
    algorithms internally to see if there are any cycles 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 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 lines of code.</SPAN></DIV>
    <DIV><SPAN></SPAN> </DIV>
    <DIV><SPAN>Finally where do I need to present this writeup ?<VAR 
    id=yiv1757882316yui-ie-cursor></VAR></SPAN></DIV>
    <DIV><SPAN></SPAN> </DIV>
    <DIV><SPAN>Thanks & Regards,</SPAN></DIV>
    <DIV><SPAN>Rohit Kumar</SPAN></DIV>
    <DIV><BR></DIV>
    <DIV 
    style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">
    <DIV 
    style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">
    <DIV dir=ltr><FONT size=2 face=Arial><B><SPAN 
    style="FONT-WEIGHT: bold">From:</SPAN></B> <A 
    class=yiv1757882316moz-txt-link-rfc2396E 
    href="mailto:concurrency-interest-request@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-request@cs.oswego.edu">"concurrency-interest-request@cs.oswego.edu"</A> 
    <A class=yiv1757882316moz-txt-link-rfc2396E 
    href="mailto:concurrency-interest-request@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-request@cs.oswego.edu"><concurrency-interest-request@cs.oswego.edu></A><BR><B><SPAN 
    style="FONT-WEIGHT: bold">To:</SPAN></B> <A 
    class=yiv1757882316moz-txt-link-abbreviated 
    href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A> 
    <BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, 16 April 
    2012 10:50 PM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
    Concurrency-interest Digest, Vol 87, Issue 27<BR></FONT></DIV><BR>Send 
    Concurrency-interest mailing list submissions to<BR>    <A 
    href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A><BR><BR>To 
    subscribe or unsubscribe via the World Wide Web, visit<BR>    
    <A href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><BR>or, 
    via email, send a message with subject or body 'help' 
    to<BR>    <A 
    href="mailto:concurrency-interest-request@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-request@cs.oswego.edu">concurrency-interest-request@cs.oswego.edu</A><BR><BR>You 
    can reach the person managing the list at<BR>    <A 
    href="mailto:concurrency-interest-owner@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-owner@cs.oswego.edu">concurrency-interest-owner@cs.oswego.edu</A><BR><BR>When 
    replying, please edit your Subject line so it is more specific<BR>than "Re: 
    Contents of Concurrency-interest digest..."<BR><BR><BR>Today's 
    Topics:<BR><BR>  1. Re: CountedCompleters (Wolfgang Baltes)<BR>  
    2. Re: Java Deadlocks prevented (Boehm, Hans)<BR>  3. Re: Java 
    Deadlocks prevented (Nathan Reynolds)<BR>  4. Re: Concurrency-interest 
    Digest, Vol 87,    Issue 26 (Java<BR>      
    deadlock prevented) (Rohit 
    Kumar)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 
    1<BR>Date: Mon, 16 Apr 2012 18:01:50 +0200<BR>From: Wolfgang Baltes <<A 
    href="mailto:wolfgang.baltes@laposte.net" rel=nofollow target=_blank 
    ymailto="mailto:wolfgang.baltes@laposte.net">wolfgang.baltes@laposte.net</A>><BR>To: 
    <A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A><BR>Subject: 
    Re: [concurrency-interest] CountedCompleters<BR>Message-ID: <<A 
    href="mailto:4F8C426E.6090704@laposte.net" rel=nofollow target=_blank 
    ymailto="mailto:4F8C426E.6090704@laposte.net">4F8C426E.6090704@laposte.net</A>><BR>Content-Type: 
    text/plain; charset=ISO-8859-1; format=flowed<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 memory 
    <BR>footprint.<BR><BR>Wolfgang.<BR><BR>On 2012-04-16 16:48, Wolfgang Baltes 
    wrote:<BR>> Thanks, Doug, for a this addition to the FJ framework. I 
    think that<BR>> CountedCompleter will address the needs of an entire 
    class of<BR>> applications in an efficient and simple to use 
    manner.<BR>><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>> 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>> enhancements I would like to suggest:<BR>><BR>> 1: 
    Symmetrically to onCompletion(), provide<BR>> 
    onExceptionalCompletion(Throwable). This allows filtering exception<BR>> 
    propagation. There are cases where the propagation of the exception 
    is<BR>> desired, and others where a corrective action is taken instead, 
    such<BR>> as 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<BR>> I 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-hearted anyway!?)<BR>><BR>> 
    3: Provide a method to join a task that is not forked and/or not<BR>> 
    completable, while minimizing worker thread blocking. For example,<BR>> 
    CountedCompleter allows creating chains 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 creation of other worker threads, ultimately 
    running out of memory<BR>> or reaching the thread count limit. If this 
    task is not forked, then<BR>> join()/quietlyJoin() will block the worker 
    thread. The following code<BR>> is my (inexpert) attempt to provide a 
    remedy. It is based on the<BR>> assumption that a task that depends on 
    others for completion is not<BR>> forked until all dependencies are 
    resolved. For example, a<BR>> CountedCompleter implementing 
    CompletionHandler would fork itself<BR>> ("implicit fork") when the IO 
    operation is done. This works very well<BR>> in my test cases, but at 
    this time I would not claim it to be<BR>> universally applicable or error 
    free. It is shown here more to<BR>> demonstrate the attempt 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 = 16;<BR>>        static final long 
    WAIT_TIMEOUT = 1_000;    // Timeout in<BR>> 
    microseconds.<BR>><BR>>        public final void 
    quietlyJoinUnforked() {<BR>>            
    this.doJoinUnforked(false);<BR>>        
    }<BR>><BR>>        public final void 
    quietlyJoinUnforkedInterruptibly()<BR>>        throws 
    InterruptedException {<BR>>            if 
    (this.doJoinUnforked(true)) {<BR>>          
          throw new InterruptedException();<BR>>    
            }<BR>>        
    }<BR>><BR>>        public final boolean 
    doJoinUnforked(final boolean<BR>> interruptibly) {<BR>>    
            int retries = RETRIES;<BR>>    
            boolean wasInterrupted = false;<BR>>  
              while (!this.isDone()) {<BR>>  
                  ForkJoinTask<?> 
    t;<BR>>                if ((t = 
    pollTask()) != null) {<BR>>            
            t.quietlyInvoke();<BR>>      
                  if (t == this) 
    {<BR>>                  
          break;<BR>>            
            }<BR>>          
          }<BR>>            
        else {<BR>>              
          if (retries-- > 0) {<BR>>      
                      
    Thread.yield();<BR>>              
              continue;<BR>>      
                  }<BR>>    
                    wasInterrupted = 
    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 retrieve<BR>>      
                      // the task's 
    result or exception.<BR>>              
              this.get(WAIT_TIMEOUT, 
    TimeUnit.MICROSECONDS);<BR>>            
                break;<BR>>      
                  }<BR>>    
                    catch (final 
    InterruptedException consumed) {<BR>>          
                  if (!interruptibly) 
    {<BR>>                  
              wasInterrupted = true;<BR>>  
                          
        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>>    
                    }<BR>>  
                  }<BR>>    
                retries = RETRIES;<BR>>  
              }<BR>>        
        if (wasInterrupted && !interruptibly) {<BR>>  
                  
    Thread.currentThread().interrupt();<BR>>        
            return false;<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,<BR>> reduces 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>> (recreational?) freedom in joining the right and left 
    sub-tasks in any<BR>> order. It works in cases where no sub-task is 
    forked explicitly. I<BR>> observed that worker thread blocking only 
    occurs towards the end of a<BR>> large recursion, suggesting that worker 
    threads only block - as<BR>> intended - when there is no other work 
    available (sometimes while<BR>> implicit forking has not yet 
    happened).<BR>><BR>> Wolfgang.<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>>> CountedCompleter, 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 may (or may not) take a lot of time to execute.<BR>>> As is the 
    case with JDK7 async IO and other completion-based<BR>>> frameworks, 
    the most common path to efficiency is for such tasks<BR>>> to arrange 
    continuation actions that occur upon their completion.<BR>>> The main 
    twist for CountedCompleters 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>>> reminiscent of other FJ-like frameworks such 
    as Intel TBB,<BR>>> CountedCompleters are designed to fit smoothly 
    with other<BR>>> kinds of ForkJoinTasks (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 same time, the CountedCompleter class 
    exposes enough<BR>>> mechanics to allow all sorts of tweaks that 
    people can use<BR>>> to improve performance.<BR>>> In 
    particular, in addition 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>>> 
    collection because GC can have similar impact on task 
    variability.<BR>>><BR>>> Even though targeted for JDK8, versions 
    of CountedCompleter<BR>>> appear in the jsr166y and main repositories, 
    not jsr166e. This is<BR>>> because they require a non-public hook into 
    modified ForkJoinTask<BR>>> exception handling mechanics in order to 
    properly propagate<BR>>> exceptional completions. For sources, docs, 
    and jar files, see<BR>>> the usual links at<BR>>> <A 
    href="http://gee.cs.oswego.edu/dl/concurrency-interest/index.html" 
    rel=nofollow 
    target=_blank>http://gee.cs.oswego.edu/dl/concurrency-interest/index.html</A><BR>>><BR>>> 
    The API docs include more details and some examples:<BR>>> <A 
    href="http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CountedCompleter.html" 
    rel=nofollow 
    target=_blank>http://gee.cs.oswego.edu/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<BR>>> 
    illustrate<BR>>> other usages. See CCBoxedLongSort and CCJacobi 
    in<BR>>> <A 
    href="http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/" 
    rel=nofollow 
    target=_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 suggestions<BR>>> 
    (hopefully based on usage experience) would be 
    welcome.<BR>>><BR>>> -Doug<BR>>><BR>>><BR>>> 
    _______________________________________________<BR>>> 
    Concurrency-interest mailing list<BR>>> <A 
    href="mailto:Concurrency-interest@cs.oswego.edu" rel=nofollow target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A><BR>>> 
    <A href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><BR>>><BR>> 
    _______________________________________________<BR>> Concurrency-interest 
    mailing list<BR>> <A href="mailto:Concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A><BR>> 
    <A href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><BR>><BR><BR><BR>------------------------------<BR><BR>Message: 
    2<BR>Date: Mon, 16 Apr 2012 16:38:00 +0000<BR>From: "Boehm, Hans" <<A 
    href="mailto:hans.boehm@hp.com" rel=nofollow target=_blank 
    ymailto="mailto:hans.boehm@hp.com">hans.boehm@hp.com</A>><BR>To: Andrew 
    Haley <<A href="mailto:aph@redhat.com" rel=nofollow target=_blank 
    ymailto="mailto:aph@redhat.com">aph@redhat.com</A>>,<BR>    
    "<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>"<BR>    
    <<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>><BR>Subject: 
    Re: [concurrency-interest] Java Deadlocks 
    prevented<BR>Message-ID:<BR>    <<A 
    href="mailto:A3E67C2071F49C4CBC4F17E6D77CDDD235543F5B@G4W3299.americas.hpqcorp.net" 
    rel=nofollow target=_blank 
    ymailto="mailto:A3E67C2071F49C4CBC4F17E6D77CDDD235543F5B@G4W3299.americas.hpqcorp.net">A3E67C2071F49C4CBC4F17E6D77CDDD235543F5B@G4W3299.americas.hpqcorp.net</A>><BR>    
    <BR>Content-Type: text/plain; charset="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 program analysis and scheduling to avoid 
    lock-based deadlocks?  (Hopefully 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 arise?<BR><BR>Hans<BR><BR>> -----Original 
    Message-----<BR>> From: <A 
    href="mailto:concurrency-interest-bounces@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</A> 
    [<A class=yiv1757882316moz-txt-link-freetext href="mailto:concurrency" 
    rel=nofollow target=_blank 
    ymailto="mailto:concurrency">mailto:concurrency</A>-<BR>> <A 
    href="mailto:interest-bounces@cs.oswego.edu" rel=nofollow target=_blank 
    ymailto="mailto:interest-bounces@cs.oswego.edu">interest-bounces@cs.oswego.edu</A>] 
    On Behalf Of Andrew Haley<BR>> Sent: Monday, April 16, 2012 4:34 
    AM<BR>> To: <A href="mailto:concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A><BR>> 
    Subject: Re: [concurrency-interest] Java Deadlocks prevented<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 the deadlock from<BR>> 
    > occuring by detecting it in advance. This can be used across 
    the<BR>> > systems 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 feedback.<BR>> That's how it 
    always works.  If your idea really works, people will<BR>> use 
    it.<BR>> <BR>> Andrew.<BR>> 
    _______________________________________________<BR>> Concurrency-interest 
    mailing list<BR>> <A href="mailto:Concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A><BR>> 
    <A href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/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="mailto:nathan.reynolds@oracle.com" rel=nofollow target=_blank 
    ymailto="mailto:nathan.reynolds@oracle.com">nathan.reynolds@oracle.com</A>><BR>To: 
    "Boehm, Hans" <<A href="mailto:hans.boehm@hp.com" rel=nofollow 
    target=_blank 
    ymailto="mailto:hans.boehm@hp.com">hans.boehm@hp.com</A>><BR>Cc: "<A 
    href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>"<BR>    
    <<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>><BR>Subject: 
    Re: [concurrency-interest] Java Deadlocks prevented<BR>Message-ID: <<A 
    href="mailto:4F8C52A4.70002@oracle.com" rel=nofollow target=_blank 
    ymailto="mailto:4F8C52A4.70002@oracle.com">4F8C52A4.70002@oracle.com</A>><BR>Content-Type: 
    text/plain; charset="iso-8859-1"; Format="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 request a refund.<BR><BR>How much 
    does deadlock prevention cost?  Is the cost on the thread that 
    <BR>acquires locks or is it in a background thread?<BR><BR>Each time 
    processors or systems increase the number of cores, I find we <BR>have 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 prevention 
    <BR>increase the critical region of locks?  If so, this will definitely 
    <BR>reduce the scalability of the system if it impacts the 1 bottlenecking 
    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 thin 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="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds" 
    rel=nofollow 
    target=_blank>http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds</A>> 
    | <BR>Consulting Member of Technical Staff | 602.333.9091<BR>Oracle PSR 
    Engineering <<A href="http://psr.us.oracle.com/" rel=nofollow 
    target=_blank>http://psr.us.oracle.com/</A>> | Server 
    Technology<BR><BR>On 4/16/2012 9:38 AM, Boehm, Hans wrote:<BR>> Important 
    questions to consider when you write it up:<BR>><BR>> How does it 
    compare to something like Gadara that uses whole program analysis and 
    scheduling to avoid lock-based deadlocks?  (Hopefully 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 
    arise?<BR>><BR>> Hans<BR>><BR>>> -----Original 
    Message-----<BR>>> From: <A 
    href="mailto:concurrency-interest-bounces@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</A> 
    [<A class=yiv1757882316moz-txt-link-freetext href="mailto:concurrency" 
    rel=nofollow target=_blank 
    ymailto="mailto:concurrency">mailto:concurrency</A>-<BR>>> <A 
    href="mailto:interest-bounces@cs.oswego.edu" rel=nofollow target=_blank 
    ymailto="mailto:interest-bounces@cs.oswego.edu">interest-bounces@cs.oswego.edu</A>] 
    On Behalf Of Andrew Haley<BR>>> Sent: Monday, April 16, 2012 4:34 
    AM<BR>>> To: <A href="mailto:concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A><BR>>> 
    Subject: Re: [concurrency-interest] Java Deadlocks 
    prevented<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 the deadlock from<BR>>>> occuring by detecting it in 
    advance. This can be used across the<BR>>>> systems 
    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>>> Write it up, maybe present it to a 
    conference, and wait for feedback.<BR>>> That's how it always 
    works.  If your idea really works, people will<BR>>> use 
    it.<BR>>><BR>>> Andrew.<BR>>> 
    _______________________________________________<BR>>> 
    Concurrency-interest mailing list<BR>>> <A 
    href="mailto:Concurrency-interest@cs.oswego.edu" rel=nofollow target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A><BR>>> 
    <A href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><BR>> 
    _______________________________________________<BR>> Concurrency-interest 
    mailing list<BR>> <A href="mailto:Concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A><BR>> 
    <A href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><BR>-------------- 
    next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: 
    <<A 
    href="http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120416/7ea89bb3/attachment-0001.html" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120416/7ea89bb3/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 
    4<BR>Date: Tue, 17 Apr 2012 01:20:15 +0800 (SGT)<BR>From: Rohit Kumar <<A 
    href="mailto:rohitk242@yahoo.co.in" rel=nofollow target=_blank 
    ymailto="mailto:rohitk242@yahoo.co.in">rohitk242@yahoo.co.in</A>><BR>To: 
    "<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>"<BR>    
    <<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>><BR>Subject: 
    Re: [concurrency-interest] Concurrency-interest Digest, 
    Vol<BR>    87,    Issue 26 (Java deadlock 
    prevented)<BR>Message-ID:<BR>    <<A 
    href="mailto:1334596815.27848.YahooMailNeo@web193403.mail.sg3.yahoo.com" 
    rel=nofollow target=_blank 
    ymailto="mailto:1334596815.27848.YahooMailNeo@web193403.mail.sg3.yahoo.com">1334596815.27848.YahooMailNeo@web193403.mail.sg3.yahoo.com</A>><BR>Content-Type: 
    text/plain; charset="iso-8859-1"<BR><BR>Andrew:<BR>?<BR>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 
    ?<BR>?<BR>Waiting for your early reply once again.<BR>?<BR>Thanks & 
    Regards,<BR>Rohit Kumar<BR><BR>From: "<A 
    href="mailto:concurrency-interest-request@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-request@cs.oswego.edu">concurrency-interest-request@cs.oswego.edu</A>" 
    <<A href="mailto:concurrency-interest-request@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-request@cs.oswego.edu">concurrency-interest-request@cs.oswego.edu</A>><BR>To: 
    <A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@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-interest mailing list 
    submissions to<BR>??? <A href="mailto:concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A><BR><BR>To 
    subscribe or unsubscribe via the World Wide Web, visit<BR>??? <A 
    href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><BR>or, 
    via email, send a message with subject or body 'help' to<BR>??? <A 
    href="mailto:concurrency-interest-request@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-request@cs.oswego.edu">concurrency-interest-request@cs.oswego.edu</A><BR><BR>You 
    can reach the person managing the list at<BR>??? <A 
    href="mailto:concurrency-interest-owner@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-owner@cs.oswego.edu">concurrency-interest-owner@cs.oswego.edu</A><BR><BR>When 
    replying, please edit your Subject line so it is more specific<BR>than "Re: 
    Contents of Concurrency-interest 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 Deadlocks prevented (Andrew 
    Haley)<BR>? 4. Re: CountedCompleters (Wolfgang 
    Baltes)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 
    1<BR>Date: Mon, 16 Apr 2012 19:03:59 +0800 (SGT)<BR>From: Rohit Kumar <<A 
    href="mailto:rohitk242@yahoo.co.in" rel=nofollow target=_blank 
    ymailto="mailto:rohitk242@yahoo.co.in">rohitk242@yahoo.co.in</A>><BR>To: 
    "<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>"<BR>??? 
    <<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>><BR>Cc: 
    "<A href="mailto:concurrency-interest-owner@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-owner@cs.oswego.edu">concurrency-interest-owner@cs.oswego.edu</A>"<BR>??? 
    <<A href="mailto:concurrency-interest-owner@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-owner@cs.oswego.edu">concurrency-interest-owner@cs.oswego.edu</A>><BR>Subject: 
    [concurrency-interest] (no subject)<BR>Message-ID:<BR>??? <<A 
    href="mailto:1334574239.81244.YahooMailNeo@web193402.mail.sg3.yahoo.com" 
    rel=nofollow target=_blank 
    ymailto="mailto:1334574239.81244.YahooMailNeo@web193402.mail.sg3.yahoo.com">1334574239.81244.YahooMailNeo@web193402.mail.sg3.yahoo.com</A>><BR>Content-Type: 
    text/plain; charset="iso-8859-1"<BR><BR>Hi All,<BR>?<BR>I have found a way 
    of preventing deadlocks in java. The methodology(which is code) completely 
    prevents the deadlock from accuring by detecting 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 next jdk release.<BR>?<BR>Thanks & 
    Regards,<BR>Rohit Kumar<BR>-------------- next part --------------<BR>An 
    HTML attachment was scrubbed...<BR>URL: <<A 
    href="http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120416/a6588341/attachment-0001.html" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120416/a6588341/attachment-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="mailto:rohitk242@yahoo.co.in" rel=nofollow target=_blank 
    ymailto="mailto:rohitk242@yahoo.co.in">rohitk242@yahoo.co.in</A>><BR>To: 
    "<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>"<BR>??? 
    <<A href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A>><BR>Cc: 
    "<A href="mailto:concurrency-interest-owner@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-owner@cs.oswego.edu">concurrency-interest-owner@cs.oswego.edu</A>"<BR>??? 
    <<A href="mailto:concurrency-interest-owner@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:concurrency-interest-owner@cs.oswego.edu">concurrency-interest-owner@cs.oswego.edu</A>><BR>Subject: 
    [concurrency-interest] Java Deadlocks prevented<BR>Message-ID:<BR>??? <<A 
    href="mailto:1334574382.90584.YahooMailNeo@web193403.mail.sg3.yahoo.com" 
    rel=nofollow target=_blank 
    ymailto="mailto:1334574382.90584.YahooMailNeo@web193403.mail.sg3.yahoo.com">1334574382.90584.YahooMailNeo@web193403.mail.sg3.yahoo.com</A>><BR>Content-Type: 
    text/plain; charset="utf-8"<BR><BR><BR><BR>Hi All,<BR><BR>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. <BR><BR>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.<BR><BR>Thanks & Regards,<BR>Rohit Kumar<BR>-------------- 
    next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: 
    <<A 
    href="http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120416/064a4873/attachment-0001.html" 
    rel=nofollow 
    target=_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="mailto:aph@redhat.com" rel=nofollow target=_blank 
    ymailto="mailto:aph@redhat.com">aph@redhat.com</A>><BR>To: <A 
    href="mailto:concurrency-interest@cs.oswego.edu" rel=nofollow target=_blank 
    ymailto="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</A><BR>Subject: 
    Re: [concurrency-interest] Java Deadlocks prevented<BR>Message-ID: <<A 
    href="mailto:4F8C0399.8040301@redhat.com" rel=nofollow target=_blank 
    ymailto="mailto:4F8C0399.8040301@redhat.com">4F8C0399.8040301@redhat.com</A>><BR>Content-Type: 
    text/plain; charset=ISO-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>> methodology(which is code) completely prevents the deadlock 
    from<BR>> occuring by detecting it in advance. This can be used across 
    the<BR>> systems 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 feedback.<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 Baltes <<A 
    href="mailto:wolfgang.baltes@laposte.net" rel=nofollow target=_blank 
    ymailto="mailto:wolfgang.baltes@laposte.net">wolfgang.baltes@laposte.net</A>><BR>To: 
    "<A href="mailto:Concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A>"<BR>??? 
    <<A href="mailto:Concurrency-interest@cs.oswego.edu" rel=nofollow 
    target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A>><BR>Subject: 
    Re: [concurrency-interest] CountedCompleters<BR>Message-ID: <<A 
    href="mailto:4F8C313F.2080308@laposte.net" rel=nofollow target=_blank 
    ymailto="mailto:4F8C313F.2080308@laposte.net">4F8C313F.2080308@laposte.net</A>><BR>Content-Type: 
    text/plain; charset=ISO-8859-1; format=flowed<BR><BR>Thanks, Doug, for a 
    this addition to the FJ framework. I think that <BR>CountedCompleter will 
    address the needs of an entire class of <BR>applications in an efficient and 
    simple to use manner.<BR><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 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 
    <BR>propagation. There are cases where the propagation of the exception is 
    <BR>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-hearted anyway!?)<BR><BR>3: Provide a method to join a task that 
    is not forked and/or not <BR>completable, while minimizing worker thread 
    blocking. For example, <BR>CountedCompleter allows creating chains of 
    dependent tasks. Unless 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, joining it will <BR>block the worker thread. I 
    noticed (and my testing is limited to a few <BR>test cases and therefore not 
    representative) the blocking and the <BR>creation of other worker threads, 
    ultimately running out of memory or <BR>reaching the thread count limit. If 
    this task is not forked, then <BR>join()/quietlyJoin() will block the worker 
    thread. The following 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 CountedCompleter <BR>implementing CompletionHandler would fork 
    itself ("implicit fork") when <BR>the IO operation is done. This works very 
    well in my test cases, 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 structures, this <BR>can be done more elegantly and 
    more reliably.<BR><BR>? ? ? ? static final int RETRIES = 16;<BR>? ? ? ? 
    static final long WAIT_TIMEOUT = 1_000;? ? // Timeout in 
    <BR>microseconds.<BR><BR>? ? ? ? public final void quietlyJoinUnforked() 
    {<BR>? ? ? ? ? ? this.doJoinUnforked(false);<BR>? ? ? ? }<BR><BR>? ? ? ? 
    public final void quietlyJoinUnforkedInterruptibly()<BR>? ? ? ? throws 
    InterruptedException {<BR>? ? ? ? ? ? if (this.doJoinUnforked(true)) {<BR>? 
    ? ? ? ? ? ? ? throw new InterruptedException();<BR>? ? ? ? ? ? }<BR>? ? ? ? 
    }<BR><BR>? ? ? ? public final boolean doJoinUnforked(final boolean 
    interruptibly) {<BR>? ? ? ? ? ? int retries = RETRIES;<BR>? ? ? ? ? ? 
    boolean wasInterrupted = false;<BR>? ? ? ? ? ? while (!this.isDone()) {<BR>? 
    ? ? ? ? ? ? ? ForkJoinTask<?> t;<BR>? ? ? ? ? ? ? ? if ((t = 
    pollTask()) != null) {<BR>? ? ? ? ? ? ? ? ? ? t.quietlyInvoke();<BR>? ? ? ? 
    ? ? ? ? ? ? if (t == this) {<BR>? ? ? ? ? ? ? ? ? ? ? ? break;<BR>? ? ? ? ? 
    ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? else {<BR>? ? ? ? ? ? ? 
    ? ? ? if (retries-- > 0) {<BR>? ? ? ? ? ? ? ? ? ? ? ? 
    Thread.yield();<BR>? ? ? ? ? ? ? ? ? ? ? ? continue;<BR>? ? ? ? ? ? ? ? ? ? 
    }<BR>? ? ? ? ? ? ? ? ? ? wasInterrupted = 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 retrieve<BR>? ? ? ? ? ? ? ? ? ? ? ? // the 
    task's result or exception.<BR>? ? ? ? ? ? ? ? ? ? ? ? 
    this.get(WAIT_TIMEOUT, TimeUnit.MICROSECONDS);<BR>? ? ? ? ? ? ? ? ? ? ? ? 
    break;<BR>? ? ? ? ? ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? ? ? catch (final 
    InterruptedException consumed) {<BR>? ? ? ? ? ? ? ? ? ? ? ? if 
    (!interruptibly) {<BR>? ? ? ? ? ? ? ? ? ? ? ? ? ? wasInterrupted = 
    true;<BR>? ? ? ? ? ? ? ? ? ? ? ? ? ? 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>? ? ? ? 
    ? ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? }<BR>? ? ? ? ? ? ? ? retries = 
    RETRIES;<BR>? ? ? ? ? ? }<BR>? ? ? ? ? ? if (wasInterrupted && 
    !interruptibly) {<BR>? ? ? ? ? ? ? ? 
    Thread.currentThread().interrupt();<BR>? ? ? ? ? ? ? ? return false;<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>threads), and allows for some extra (recreational?) freedom in joining 
    <BR>the 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 worker 
    <BR>threads only block - as intended - when there is no other work available 
    <BR>(sometimes while implicit forking has not yet 
    happened).<BR><BR>Wolfgang.<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>> CountedCompleter, 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 may (or may not) take a lot of time to 
    execute.<BR>> As is the case with JDK7 async IO and other 
    completion-based<BR>> frameworks, the most common path to efficiency is 
    for such tasks<BR>> to arrange continuation actions that occur upon their 
    completion.<BR>> The main twist for CountedCompleters 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>> reminiscent of other 
    FJ-like frameworks such as Intel TBB,<BR>> CountedCompleters are designed 
    to fit smoothly with other<BR>> kinds of ForkJoinTasks (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 same time, the 
    CountedCompleter class exposes enough<BR>> mechanics to allow all sorts 
    of tweaks that people can use<BR>> to improve performance.<BR>> In 
    particular, in addition 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>> collection 
    because GC can have similar impact on task variability.<BR>><BR>> Even 
    though targeted for JDK8, versions of CountedCompleter<BR>> appear in the 
    jsr166y and main repositories, not jsr166e. This is<BR>> because they 
    require a non-public hook into modified ForkJoinTask<BR>> exception 
    handling mechanics in order to properly propagate<BR>> exceptional 
    completions. For sources, docs, and jar files, see<BR>> the usual links 
    at <BR>> <A 
    href="http://gee.cs.oswego.edu/dl/concurrency-interest/index.html" 
    rel=nofollow 
    target=_blank>http://gee.cs.oswego.edu/dl/concurrency-interest/index.html</A><BR>><BR>> 
    The API docs include more details and some examples:<BR>> <A 
    href="http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CountedCompleter.html" 
    rel=nofollow 
    target=_blank>http://gee.cs.oswego.edu/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 
    CCJacobi in<BR>> <A 
    href="http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/" 
    rel=nofollow 
    target=_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 suggestions<BR>> (hopefully 
    based on usage experience) would be welcome.<BR>><BR>> 
    -Doug<BR>><BR>><BR>> 
    _______________________________________________<BR>> Concurrency-interest 
    mailing list<BR>> <A href="mailto:Concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A><BR>> 
    <A href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><BR>><BR><BR><BR>------------------------------<BR><BR>_______________________________________________<BR>Concurrency-interest 
    mailing list<BR><A href="mailto:Concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A><BR><A 
    href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_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="http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120417/75746dcb/attachment.html" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120417/75746dcb/attachment.html</A>><BR><BR>------------------------------<BR><BR>_______________________________________________<BR>Concurrency-interest 
    mailing list<BR><A href="mailto:Concurrency-interest@cs.oswego.edu" 
    rel=nofollow target=_blank 
    ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A><BR><A 
    href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" 
    rel=nofollow 
    target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A><BR><BR><BR>End 
    of Concurrency-interest Digest, Vol 87, Issue 
    27<BR>****************************************************<BR><BR><BR></DIV></DIV></DIV><BR>
    <FIELDSET class=yiv1757882316mimeAttachmentHeader></FIELDSET> <BR><PRE>_______________________________________________
Concurrency-interest mailing list
<A class=yiv1757882316moz-txt-link-abbreviated href="mailto:Concurrency-interest@cs.oswego.edu" rel=nofollow target=_blank ymailto="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A>
<A class=yiv1757882316moz-txt-link-freetext href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel=nofollow target=_blank>http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A>
</PRE></BLOCKQUOTE></DIV></DIV>
  <META content=on 
http-equiv=x-dns-prefetch-control><BR><BR></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>