[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls from within Java threads

[Jiang Wu]

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

[Jiang Wu]

 -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