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
