[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls from within Java threads
Hmm, I just realized that the issue is the Interp.eval code isn't thread
safe, so it just needs to run in a single Java thread (not necessarily the
Java main thread). So the code I suggested below won't work but you get the
idea -- have the code sanity check the call and not silently allow someone
to stumble on a known limitation in the code...
thanks
- Mike
Resent-Date: Tue, 25 Jul 2000 13:11:49 -0700 (PDT)
X-Sender: [EMAIL PROTECTED]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 25 Jul 2000 14:09:44 -0600
To: Mo DeJong [EMAIL PROTECTED]
From: Mike Schwartz [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Resent-From: [EMAIL PROTECTED]
X-Mailing-List: [EMAIL PROTECTED] archive/latest/1044
X-Loop: [EMAIL PROTECTED]
Resent-Sender: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls from
within
Java threads
Hi Mo,
I have a suggestion: put this at the top of thetcl.lang.Interp.eval() code:
if (!(Thread.currentThread().getName().equals("main"))) {
throw new TclException(
"tcl.lang.Interp.eval() cannot be called from any Java
thread other than main."
+ "Please see
http://www-cs-students.stanford.edu/~jwu/Using_Tcl_in_Java.html"
);
}
(or whatever web reference you think will be around and stable --
probably should be at scriptics.com)
That way, people will find out about the shortcoming directly, rather
than having to dig into their code and figure it out for themselves.
Thanks,
- Mike
Date: Tue, 25 Jul 2000 12:23:55 -0700 (PDT)
From: Mo DeJong [EMAIL PROTECTED]
To: Mike Schwartz [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: [Tcl Java] problem invoking tclBlend calls from within
Java threads
On Tue, 25 Jul 2000, Mike Schwartz wrote:
Hi,
I've come across another problem with tclBlend.
...
Synopsis: if you start up a Java program from Tcl and that Java program
creates multiple threads that try to invoke tcl.lang.Interp.eval() (with
appropriate synchronization so they are not interspersing commands with
each other), the threads hang waiting for the eval call to complete.
We really need to embed a .wav file in tcljava.jar that plays
"You can't do that dave" when someone tries to call Interp.eval()
from another thread. If you try this, things wil get really hosed
(as you found out).
Here are some posts that cover how to do it correctly.
http://www.mail-archive.com/tcljava@scriptics.com/msg00647.html
http://www.mail-archive.com/tcljava@scriptics.com/msg00604.html
http://www.mail-archive.com/tcljava@scriptics.com/msg00619.html
Jiang also wrote up a nice overview of the situation, you
can find his paper here:
http://www-cs-students.stanford.edu/~jwu/Using_Tcl_in_Java.html
Getting all of this shared knowledge back into the documentation
is on the TODO list. We also need some nice small examples that
people can look at without having to read all the API docs.
Mo DeJong
Red Hat Inc
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] problem invoking tclBlend calls from within Java threads
On Tue, 25 Jul 2000, Mike Schwartz wrote: Hmm, I just realized that the issue is the Interp.eval code isn't thread safe, so it just needs to run in a single Java thread (not necessarily the Java main thread). So the code I suggested below won't work but you get the idea -- have the code sanity check the call and not silently allow someone to stumble on a known limitation in the code... thanks - Mike It is not a "known limitation". The fact that most of the methods in the interp class are not thread safe is by design. The thread safe event queue is the way to go. I am open to suggestions as to how we could help people to not make this mistake in the future. I think better documentation is the best approach, but writing docs is boring so folks do not seem to want to help with that. Mo DeJong Red Hat Inc 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] problem invoking tclBlend calls from within Java threads
Well, this is a matter of personal taste I suppose, but in my view making non-threadsafe code in this day-and-age, especially code that is intended to interoperate with a language (Java) that is designed to make it easy to build threaded apps, is problematic. Asking programmers to build event queues to avoid the problem seems like not a great solution, because (a) it represents a language non-orthogonality gotcha, and (b) it makes it more work for programmers to accomplish what they want. I think if it's going to be non-thread safe then the code should sanity check for thread-crossing calls, perhaps with #ifdef's so performance concerns can be removed for people who don't want the sanity checks. But, I already mentioned the sanity check idea, and I don't mean to belabor the point... Thanks for all your work on tclBlend - Mike Date: Tue, 25 Jul 2000 15:31:39 -0700 (PDT) From: Mo DeJong [EMAIL PROTECTED] To: Mike Schwartz [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls from within Java threads On Tue, 25 Jul 2000, Mike Schwartz wrote: Hmm, I just realized that the issue is the Interp.eval code isn't thread safe, so it just needs to run in a single Java thread (not necessarily the Java main thread). So the code I suggested below won't work but you get the idea -- have the code sanity check the call and not silently allow someone to stumble on a known limitation in the code... thanks - Mike It is not a "known limitation". The fact that most of the methods in the interp class are not thread safe is by design. The thread safe event queue is the way to go. I am open to suggestions as to how we could help people to not make this mistake in the future. I think better documentation is the best approach, but writing docs is boring so folks do not seem to want to help with that. Mo DeJong Red Hat Inc 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] problem invoking tclBlend calls from within Java threads
On Tue, 25 Jul 2000, Mike Schwartz wrote: Well, this is a matter of personal taste I suppose, but in my view making non-threadsafe code in this day-and-age, especially code that is intended to interoperate with a language (Java) that is designed to make it easy to build threaded apps, is problematic. Asking programmers to build event queues to avoid the problem seems like not a great solution, because (a) it represents a language non-orthogonality gotcha, and (b) it makes it more work for programmers to accomplish what they want. Tcl/Java is thread safe, it just does not synchronize on calls to Interp.eval(). This is a very good thing, even if it does not seem that way at first. When you first start playing with threads, it seems easy, just put a synchronized on every method and presto, thread safe code. Unfortunately, in the real world it does not really work that way. You can still end up with deadlocks and your code runs dog slow because of too much synchronization. Just take a look at the AWT for a great example of over-synchronization and deadlock prone code. Java has some nice synchronization primitives, but they are not a silver bullet. Tcl's use of event queues is the right way to do synchronization in a complex event based application, it is a bit more complex but it is worth it in the long run. Just look at how Sun fixed APIs in newer versions of Java, in many cases they removed synchronized blocks of code and basically said "it is up to you to be thread safe". I think if it's going to be non-thread safe then the code should sanity check for thread-crossing calls, perhaps with #ifdef's so performance concerns can be removed for people who don't want the sanity checks. I like this approach, but the problem is that there is no way to easily turn code on and off automatically (ala #ifdef) in Java. You can use final booleans to get the same behavior, but folks would need to go in and turn these extra checks on, so that kind of defeats the purpose. Mo DeJong Red Hat Inc 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] problem invoking tclBlend calls from within Java threads
I think if it's going to be non-thread safe then the code should sanity check for thread-crossing calls, perhaps with #ifdef's so performance concerns can be removed for people who don't want the sanity checks. I like this approach, but the problem is that there is no way to easily turn code on and off automatically (ala #ifdef) in Java. You can use final booleans to get the same behavior, but folks would need to go in and turn these extra checks on, so that kind of defeats the purpose. I thought it was the JNI / C code side that wasn't thread safe. You're saying it's the Interp pure Java code that's the problem? In that case you could define an abstract class with all the Interp interfaces and have 2 implementations, one thread safe and one not, and let people instantiate whichever they prefer. - Mike 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] Re: [Tcl Java] problem invoking tclBlend calls from within Java threads
In general, it is not a good idea to assume any class/method is thread safe, even in Java. Unfortunately, Java tends to give programmer a false sense of security when it comes to threading issues. In Java, it is too easy to create threads, IO packages must use threads, and synchronization keywords make people think that threads are easy to use. As people have pointed out, using thread requires careful design and implementation. Tossing around synchronized in Java code is an invitation to trouble. Tcl and Tcl/Blend uses message passing as the way to communicate between threads. This is a well design, efficient and very standard way for thread communication and data sharing. In Tcl/Blend, only the Notifier class (and may be some other static methods) is designed to be thread safe. But I do agree that there needs to be better documentation or code to help with the correct usage of the model. What if we are to add a few helper methods such as: public static tcl.lang.Interp Interp.createInterp(); which will create a thread, create an Interp to use the dedicated thread, start the event listener, and return the Interp. Or have something like this for people using TclBlend with non-threaded Tcl: public static tcl.lang.Interp Interp.getTheGlobalInterp(); which checks to see if the global interpreter is created already. If it is, returns the global Interp object. If not, create the interpreter, assigns it a thread, starts the event listener, and returns the Interp. -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: Mike Schwartz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 25, 2000 3:58 PM To: Mo DeJong Cc: [EMAIL PROTECTED] Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls from within Java threads Well, this is a matter of personal taste I suppose, but in my view making non-threadsafe code in this day-and-age, especially code that is intended to interoperate with a language (Java) that is designed to make it easy to build threaded apps, is problematic. Asking programmers to build event queues to avoid the problem seems like not a 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] Re: [Tcl Java] problem invoking tclBlend calls from within Java threads
-Original Message- From: Mike Schwartz [mailto:[EMAIL PROTECTED]] I thought it was the JNI / C code side that wasn't thread safe. You're saying it's the Interp pure Java code that's the problem? In that case you could define an abstract class with all the Interp interfaces and have 2 implementations, one thread safe and one not, and let people instantiate whichever they prefer. What is the meaning of "thread safe"? To most people, this means a method is callable from multiple threads. But in general, having thread-safe methods do not automatically produces thread safe programs. For example, let's think about a Java java.io.DataOutputStream class. The method DataOutputStream.write(int) is declared as: public synchronized void write(int b) throws IOException So can two Java threads using write(...) at the same time? Sure, they can. Does this make your program thread safe? Probably not. Here is why: Two threads are writing bytes into the same output stream. The bytes from both threads will be mixed in a random fashion in the output stream. Unless the byte order has no significance, then your program will never crash, but it won't work properly either. To use the output stream properly, a higher level synchronization is usually required. Something like: getOutputStreamLock(); out.write(b1); out.write(b2); ... releaseOutputStreamLock(); In fact, the "synchronized" part of the write method does nothing but overhead in this situation. This example is just to show that a method or a class being thread-safe does not mean a functional area of the program is thread-safe. The goal of multi-threaded programming is to design functional areas that are thread safe. Tcl + Tcl/Blend is thread-safe as a functional area even though most of its methods are not thread safe. -- Jiang Wu [EMAIL PROTECTED] 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
