[Tcl Java] Re: [Tcl Java] what I now know about the deadlock
I hope you will tell me "SOLUTION 1, and Tclblend_Init doesn't matter in this context," because that seems to fix my problem. Dr Wes Munsil wrote: Please give me your advice. I've instrumented TclBlend to look for the pattern of execution of MonitorEnter/MonitorExit calls and have learned this. The deadlock seen in my code, and now in the TclBlend regression test AutomaticSignature.test on Solaris with native threads, has these characteristics: 1) Tclblend_Init is never called. Consequently the call of MonitorEnter in that function is never executed. 2) Although Jiang's patch removes the MonitorEnter and MonitorExit calls from JAVA_LOCK and JAVA_UNLOCK, there are still other calls of MonitorEnter and MonitorExit: they occur in Exit/Enter pairs in JavaIdleProc, JavaTraceProc, JavaCmdDeleteProc, JavaCmdProc, JavaEventProc, and JavaTimerProc. 3) The sequence of events leading up to deadlock is the following: a) the main thread calls MonitorExit in JavaCmdProc b) the garbage collection thread calls MonitorExit in JavaCmdDeleteProc c) the garbage collection thread calls MonitorEnter in JavaCmdDeleteProc d) the main thread calls MonitorEnter in JavaCmdProc (and blocks) I can think of two solutions to this problem, but I don't know which is "right." SOLUTION 1. Simply remove all remaining calls of MonitorEnter and MonitorExit. SOLUTION 2. Replace all remaining calls of MonitorEnter and MonitorExit by invocations of JAVA_LOCK and JAVA_UNLOCK, respectively (which now have the MonitorEnter and MonitorExit calls removed, but which retain the fiddling with the Java environment). In either case, we should possibly discover why Tclblend_Init is not being called, and fix that. What do you think? Thank you. The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] what I now know about the deadlock
Without having looked into the innerds of TclBlend's JNI implementation (though it looks quite clean at least) I'd say that removing the monitor calls and JAVA_LOCK are probably fine. I say this because we have a decent size app (~250K lines of C/C++/Java) that uses a JNI layer I wrote. I never use locking in the JNI layer (in general) and have multithreaded access without any apparent problems (the JNI part is the backend of a Java based server that provides access to common C code.) john -Original Message- From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 14, 2000 7:40 AM To: [EMAIL PROTECTED] Subject: [Tcl Java] Re: [Tcl Java] what I now know about the deadlock I hope you will tell me "SOLUTION 1, and Tclblend_Init doesn't matter in this context," because that seems to fix my problem. Dr Wes Munsil wrote: Please give me your advice. I've instrumented TclBlend to look for the pattern of execution of MonitorEnter/MonitorExit calls and have learned this. The deadlock seen in my code, and now in the TclBlend regression test AutomaticSignature.test on Solaris with native threads, has these characteristics: 1) Tclblend_Init is never called. Consequently the call of MonitorEnter in that function is never executed. 2) Although Jiang's patch removes the MonitorEnter and MonitorExit calls from JAVA_LOCK and JAVA_UNLOCK, there are still other calls of MonitorEnter and MonitorExit: they occur in Exit/Enter pairs in JavaIdleProc, JavaTraceProc, JavaCmdDeleteProc, JavaCmdProc, JavaEventProc, and JavaTimerProc. 3) The sequence of events leading up to deadlock is the following: a) the main thread calls MonitorExit in JavaCmdProc b) the garbage collection thread calls MonitorExit in JavaCmdDeleteProc c) the garbage collection thread calls MonitorEnter in JavaCmdDeleteProc d) the main thread calls MonitorEnter in JavaCmdProc (and blocks) I can think of two solutions to this problem, but I don't know which is "right." SOLUTION 1. Simply remove all remaining calls of MonitorEnter and MonitorExit. SOLUTION 2. Replace all remaining calls of MonitorEnter and MonitorExit by invocations of JAVA_LOCK and JAVA_UNLOCK, respectively (which now have the MonitorEnter and MonitorExit calls removed, but which retain the fiddling with the Java environment). In either case, we should possibly discover why Tclblend_Init is not being called, and fix that. What do you think? Thank you. The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] what I now know about the deadlock
A small correction. My patch does NOT remove the monitor calls in JAVA_LOCK/JAVA_UNLOCK. The patch fixes problems encountered if you load Tcl into a running JVM, which is the opposite way of using TclBlend comparing how you are using TclBlend. I also think removing all instances of MonitorEnter and MonitorExit from the TclBlend code should not do any harm. -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 13, 2000 9:50 PM To: [EMAIL PROTECTED] Subject: [Tcl Java] what I now know about the deadlock 2) Although Jiang's patch removes the MonitorEnter and MonitorExit calls from JAVA_LOCK and JAVA_UNLOCK, there are still other calls of The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] what I now know about the deadlock
Sorry, you are quite correct; I was not clear. When I refered to "Jiang's patch," I actually meant "the patch at http://www.mail-archive.com/tcljava@scriptics.com/msg00598/tclblend.patch, plus Jiang's suggestion to remove the monitor calls from JAVA_LOCK and JAVA_UNLOCK." Thank you for allowing me to clarify that. Jiang Wu wrote: A small correction. My patch does NOT remove the monitor calls in JAVA_LOCK/JAVA_UNLOCK. The patch fixes problems encountered if you load Tcl into a running JVM, which is the opposite way of using TclBlend comparing how you are using TclBlend. I also think removing all instances of MonitorEnter and MonitorExit from the TclBlend code should not do any harm. -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 13, 2000 9:50 PM To: [EMAIL PROTECTED] Subject: [Tcl Java] what I now know about the deadlock 2) Although Jiang's patch removes the MonitorEnter and MonitorExit calls from JAVA_LOCK and JAVA_UNLOCK, there are still other calls of The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] what I now know about the deadlock
Mo DeJong wrote: On Tue, 13 Jun 2000, Dr Wes Munsil wrote: 1) Tclblend_Init is never called. Consequently the call of MonitorEnter in that function is never executed. That does not seem right. The Tclblend_Init method should be invoked by Tcl during the load command (like load libtclblend.so). I misinterpreted the output. When you do a "make test", it apparently does a "source all" into a single invocation of tclsh, rather than invoking tclsh anew for each test case. The invocation of Tclblend_init therefore shows up in my debugging output for ArrayObject.test (the first test case) but not AutomaticSignature.test (the second test case). The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] patch for deadlock
The patch I ended up with to solve the Solaris deadlock issue combines Jiang Wu's patch and the removal of all MonitorEnter and MonitorExit calls. The diffs between TclBlend 1.2.5 and my version are at http://idd.com/~wes/tclblendpatch. Note also that the class tcl.lang.NativeLock may now be removed. The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
