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 Wed, 25 Sep 2019 17:57:00 GMT

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

Marshall Schor edited comment on UIMA-6129 at 9/25/19 5:56 PM:
---------------------------------------------------------------

Hi, my understanding of your example: You have a main thread (let's call it T1), and make
another thread T2 for the future task, and launch it.  It references the jcas.

The T1's get(... with timeout) times out, then proceeds to access that same JCas while the
T2 is still running and making annotations.  This may cause the concurrent modification exception: 
T1 is iterating over Annotations, while, simultaneously, T2 could be adding to the the Annotation
index. causes lots of problems, including the two you saw (possible thread interlock and concurrent
modification exception).

This might also be causing the thread deadlock, when T2 modifies the JCas indexes at the same
time T1 is reading them.

A way around this could be to surround all the code in both T1 and T2 that do access to the
same JCas with a synchronization lock, to prevent both from running at the same time. 


was (Author: schor):
Hi, my understanding of your example: You have a main thread (let's call it T1), and make
another thread T2 for the future task, and launch it.  It references the jcase.

The T1's get(... with timeout) times out, then proceeds to access that same JCas while the
T2 is still running and making annotations.  This may cause the concurrent modification exception: 
T1 is iterating over Annotations, while, simultaneously, T2 could be adding to the the Annotation
index. causes lots of problems, including the two you saw (possible thread interlock and concurrent
modification exception).

This might also be causing the thread deadlock, when T2 modifies the JCas indexes at the same
time T1 is reading them.

A way around this could be to surround all the code in both T1 and T2 that do access to the
same JCas with a synchronization lock, to prevent both from running at the same time. 

> 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