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
