> -----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
