Menu
▾
▴
#841 High-stress multithreading: Rexx seems to hang at terminatio
File is too large to upload with this report, it is available as
"MT_bug_4.zip" at http://wi.wu.ac.at/rgf/tmp/ooRexx/de_bug/MT_bug_4.zip. This archive
is created for the 32-bit ooRexx interpreter. [Please note, that
accompanying files for debugging may be named "BSF4Rexx-32.*", whereas the
dll in use is named "BSF4Rexx.dll", i.e. without the bitness information.]
After download, unzip it, change into the directory "MT_bug_4" and run
"setEnvironment.cmd", which will set up the PATH and CLASSPATH environment
variables.
Then run the batch file:
run_80_testgroup.cmd
... this one will start a testgroup in which Rexx creates a Java object
that will create 27 Java threads that each creates a new Rexx interpreter
instance and run a Rexx script off it which itself will create 29 Rexx
threads to execute and interact with BSF4Rexx.
At the end of the testGroup it seems that Rexx hangs.
Discussion
Anonymous
Maybe helpful: one can control the numbers of separate Java threads (each creating and using an individual additional Rexx interpreter instance) and the number of Rexx threads in each such Java thread by locating line # 49 (setting number of Java threads) and # 50 (setting number of Rexx threads per Java thread) in the file "testUnits\bsf4rexx\rgf\F_multiThreading\80_test_MultiThreading_via_Java_threads.testGroup".
This way one can easily control the number Rexx interpreter instances that should get created and the number of Rexx threads (in one extreme setting Java threads=1, Rexx threads=1). [But please note one Rexx interpreter instance is used for running the testGroup, the Java threads will create additional Rexx interpreter instances.]
Please create a version of this with all of your debugging output turned off. This is just noise that is making it very difficult to determine where the failures are.
This version has no debug output: http://wi.wu.ac.at/rgf/tmp/ooRexx/de_bug/MT_bug_5.zip:
This is a classic deadlock situation in the test case, not a problem with the interpreter. Looking at the threads, one of the threads has an assertion failure, and is attempting to log the failure information. This thread is in the makeFailure() method in OOREXXUNIT.CLS, line 1395. It is blocked on the call to definedInFile because this is also a guarded method. Because this guarded method is defined at a different scope level than the makeFailure method, there are two guard locks required to execute this. The lock for the TestCase class (the class that defines definedInFile) is held by the execute() method call in the main thread that is running this test, so this blocks. Because this thread is holding the lock on the Assert class, all the rest of the threads are blocking on assertTrue calls. It appears that at some level of threading, some test failures start to occur, which results in this deadlock. Adding an unguarded attribute to the definedInFile and TestCaseInfo method makes the hang go away.