harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-3864) [drlvm][thread] VM sometimes hangs after ThreadGroup.setMaxPriority()
Date Tue, 19 Jun 2007 13:28:35 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506166
] 

Ilya Berezhniuk commented on HARMONY-3864:
------------------------------------------

I've found a cause of a deadlock. I looked through HARMONY-4195 design problems list and did
not found corresponding problem.
So I'll better describe this deadlock.

When deadlock happens, we have the following state:
- There are several (21) thread groups chained together as a list so as every group is a children
to another
- Top thread group contains several (20) threads which are ready to be started
- Bottom thread group contains one thread ready to finish its lifecycle
- Other thread groups contain one subgroup and contain no threads

Then threads execution goes in following order:
- One thread in top group starts and executes setMaxPriority for its group; it involves recursive
call to synchronized nonsecureSetMaxPriority for its group and all subgroups. For example,
it can perform nonsecureSetMaxPriority 10 times - so 10 top groups are loced by top thread
- Last thread in bottom thread group continues to execute and invokes Thread.detach(..) method,
which invokes synchronized group.remove(this). If thread groups are daemon groups, it involves
removing group from its parent group with synchronized parent.remove(..), because group becomes
empty; parent.remove(..) involves removing group from next parent, and so on.
- In some place in group list upper group tries to invoke nonsecureSetMaxPriority for child
group and stops on lock, because underlying group is already locked by detaching thread. Detaching
thread tries to perform parent.remove(..) and stops on lock obtained by top thread. So these
two treads are deadlocked.
- Other top threads are waiting on 'this' lock for top thread group.

Looks like problem appears because of over-synchronization on 'this'. setMaxPriority should
possibly use separate lock, or detaching threads should possibly use synchronized flag preventing
further recursion in nonsecureSetMaxPriority.

> [drlvm][thread] VM sometimes hangs after ThreadGroup.setMaxPriority()
> ---------------------------------------------------------------------
>
>                 Key: HARMONY-3864
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3864
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Windows and Linux
>            Reporter: Vera Petrashkova
>            Assignee: weldon washburn
>            Priority: Minor
>
> The following test demonstrates that sometimes VM hangs on some thread after invocation
of 
> the  method ThreadGroup.setMaxPriority(int) 
> ------------------ThreadGroupTest.java-----------------
> import java.io.*;
> public class ThreadGroupTest {
>     public static int nmbTG = 20;
>     public static int nmbTH = 20;
>     public static boolean isDaemon = false;
>     public static boolean setPrior = false;
>     public static void main(String[] args) {
>         if ((args.length >= 1) && "true".equals(args[0])) {
>             isDaemon = true;
>         }
>         if ((args.length >= 2) && "true".equals(args[1])) {
>             setPrior = true;
>         }
>         for (int t = 0; t < 100; t++) {
>             new ThreadGroupTest().test();
>             System.err.println("Step: "+t+"  finished");
>         }
>         System.err.println("Test passed");
>     }
>     public void test() {
>         ThreadGroup roottg = new ThreadGroup("root-tg");
>         roottg.setDaemon(isDaemon);
>         Thread_t [] threads1 = new Thread_t[nmbTH];
> 	for (int i = 0; i < nmbTH; i ++) {
>             threads1[i] = new Thread_t(roottg,"roottg");
>         }
>         ThreadGroup [] tg = new ThreadGroup[nmbTG];
>         Thread_t [][] threads = new Thread_t[nmbTG][nmbTH];
> 	for (int i = 0; i < nmbTG; i ++) {
>             tg[i] = new ThreadGroup(i == 0 ? roottg : tg[i-1], Integer.toString(i));
>             for (int j = 0; j < nmbTH; j++) {
>                 threads[i][j] = new Thread_t(tg[i],Integer.toString(j));
>             }
>         }
>         for (int i = 0; i < nmbTG; i ++) {
>             for (int j = 0; j < nmbTH; j++) {
>                    threads[i][j].setDaemon(tg[i].isDaemon());
>                    threads[i][j].start();
>             }
>         }
>         for (int i = 0; i < nmbTH; i ++) {
>             threads1[i].start();
>         }
>         for (int i = 0; i < nmbTG; i++) {
>             for (int j = 0; j < nmbTH; j++) {
>                 try {
>                     threads[i][j].join();
>                 } catch (Throwable e) {
>                     e.printStackTrace();
>                 }
>             }
>         }
>         for (int i = 0; i < nmbTH; i ++) {
>             try {
>                 threads1[i].join();
>             } catch (Throwable e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> }
> class Thread_t extends Thread {
>     ThreadGroup tg;
>     String id;
>     public Thread_t (ThreadGroup tg, String n) {
>         super(tg, n);
>         this.tg = tg;
>         this.id = n;
>     }
>     public void run() {
>         int mp = tg.getMaxPriority();
>         if (ThreadGroupTest.setPrior ) {
>             tg.setMaxPriority(2); 
>         }
>         String[][] str = new String[10][100];        
>         for (int i = 0; i < str.length; ++i) {
>       
>             for (int j = 0; j < str[i].length; ++j) {
>                 str[i][j] = "" + i + "" + j;
>             }
>         }
>     }    
> }
> ------------------------------------------------------------------
> Run ThreadGroupTest several times
> I can not reproduce the issue on Windows for non daemon threads.
> But it is reproducible for daemon threads on Windows and for both kinds of thread on
Linux.
> java -cp . ThreadGroupTest true true
> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or
its l
> icensors, as applicable.
> java version "1.5.0"
> pre-alpha : not complete or compatible
> svn = r537729, (May 14 2007), Windows/ia32/msvc 1310, release build
> http://incubator.apache.org/harmony
> Step: 0  finished
> Step: 1  finished
> Step: 2  finished
> Step: 3  finished
> Step: 4  finished
> Step: 5  finished
> Step: 6  finished
> Step: 7  finished
> Step: 8  finished
> Step: 9  finished
> Step: 10  finished
> Step: 11  finished
> Step: 12  finished
> java -cp . ThreadGroupTest false true
> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or
its licensors, as applicable.
> java version "1.5.0" 
> pre-alpha : not complete or compatible
> svn = r537729, (May 14 2007), Linux/ia32/gcc 3.3.3, release build
> http://incubator.apache.org/harmony
> Step: 0  finished
> Step: 1  finished
> Step: 2  finished
> This bug causes the failure of the reliability test
> api.kernel.threadgroup.EnumerateTest
> from http://issues.apache.org/jira/browse/HARMONY-2918

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message