uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (Jira)" <...@uima.apache.org>
Subject [jira] [Comment Edited] (UIMA-6129) The thread may deadlock if other thread interrupted which use jcas
Date Fri, 27 Sep 2019 13:21:00 GMT

    [ https://issues.apache.org/jira/browse/UIMA-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939442#comment-16939442
] 

Marshall Schor edited comment on UIMA-6129 at 9/27/19 1:20 PM:
---------------------------------------------------------------

Here's an approach that may work for you.

You could change the code for T2 to include something that would react to the interrupt.

(I haven't tested this, so it may be buggy)
{code:java}
 FutureTask<String> future = new FutureTask<>( () -> { long t = System.currentTimeMillis();
while (System.currentTimeMillis() - t <= 1000L) {
   Annotation annotation = new Annotation(jcas, 0, 2);
   annotation.addToIndexes(jcas);
   // be responsive to thread interruptions
   // ASSUME they will only be caused by the "cancel(true)" method of FutureTask
   // So - minor issue: if something else interrupts this thread, it will stop...
   if (Thread.currentThread.isInterrupted()) {
     return "exiting due to cancel"; 
   }

   return "success";
 });
  {code}
And, there is now a race condition - you have to in T1, wait in a loop for the Future to finish:
{code:java}
catch (TimeoutException e) { 
  future.cancel(true); 
  while(!future.isDone()) {
    Thread.sleep(100);
  }
  e.printStackTrace();
  {code}
The general principle, in task T2, in various spots, insert a test for isInterrupted, and
if found, figure out how to terminate the thread. In this simple case, you can return, but
in other cases, you might need to do a "throw", and insure that in the call stack for the
thread, there are no "catchers" for the particular exception you're throwing. 
  

 

 

 


was (Author: schor):
Here's an approach that may work for you.

You could change the code for T2 to include something that would react to the interrupt.

(I haven't tested this, so it may be buggy)
        FutureTask<String> future = new FutureTask<>( () -> {            long
t = System.currentTimeMillis();            while (System.currentTimeMillis() - t <= 1000L)
{
                Annotation annotation  = new Annotation(jcas, 0, 2);
                annotation.addToIndexes(jcas);
                // be responsive to thread interruptions
                //   ASSUME they will only be caused by the "cancel(true)" method of FutureTask
                //   So - minor issue: if something else interrupts this thread, it will stop...
                if (Thread.currentThread.isInterrupted()) {
                  return "exiting due to cancel";
                }  
            }            return "success";
        });

And, there is now a race condition - you have to in T1, wait in a loop for the Future to finish:

          catch (TimeoutException e) {
            future.cancel(true);
            while(!future.isDone()) \{Thread.sleep(100);}
            e.printStackTrace();
   
The general principle, in task T2, in various spots, insert a test for isInterrupted, and
if found, figure out how to terminate the thread.  In this simple case, you can return, but
in other cases, you might need to do a "throw", and insure that in the call stack for the
thread, there are no "catchers" for the particular exception you're throwing.  
 

 

 

 

> The thread may deadlock if other thread interrupted which use jcas 
> -------------------------------------------------------------------
>
>                 Key: UIMA-6129
>                 URL: https://issues.apache.org/jira/browse/UIMA-6129
>             Project: UIMA
>          Issue Type: Bug
>          Components: UIMA
>    Affects Versions: 2.10.4SDK
>            Reporter: li Gongrong
>            Priority: Major
>
> I use FutureTask to kill the thread spend a lot of time,but it will cause deadlock.
> {code:java}
> at sun.misc.Unsafe.park(Native Method)at sun.misc.Unsafe.park(Native Method) - parking
to wait for  <0x000000070435e808> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at org.apache.uima.jcas.impl.JCasHashMapSubMap.getReserve(JCasHashMapSubMap.java:303) at org.apache.uima.jcas.impl.JCasHashMap.getReserve(JCasHashMap.java:318)
at org.apache.uima.jcas.impl.JCasImpl.getJfsFromCaddr(JCasImpl.java:1154) at org.apache.uima.jcas.impl.JCasImpl$JCasFsGenerator.createFS(JCasImpl.java:912)
at org.apache.uima.jcas.impl.JCasImpl$JCasFsGenerator.createFS(JCasImpl.java:873) at org.apache.uima.cas.impl.CASImpl.ll_getFSForRef(CASImpl.java:3751)
at org.apache.uima.cas.impl.CASImpl.createFS(CASImpl.java:2231) at org.apache.uima.cas.impl.FSIteratorWrapper.get(FSIteratorWrapper.java:63)
at org.apache.uima.cas.impl.FSIteratorAggregate.get(FSIteratorAggregate.java:76) at org.apache.uima.cas.impl.FSIteratorImplBase.next(FSIteratorImplBase.java:66)
at org.apache.uima.cas.impl.FSIteratorImplBase.next(FSIteratorImplBase.java:32)
> {code}
> why ?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message