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
