Subj : Re: How do I use the Java API in a Thread-Safe Manner?
To   : comp.programming.threads
From : Al Koch
Date : Wed Jun 22 2005 08:16 pm

Hi David,

Thanks for your reply.  I have some follow on questions/cpomments:

> No. 'new' is threadsafe.

new may be safe, but it causes the Ctor to be triggered.  In general, who
knows what that's going to do.  So how does one determine that "new
UnsafeClass" is thread-safe?


> MessageDigest.getInstance simply asks each installed security provider
> whether it has an implementation of "SHA-1" (possibly caching the result
> for future calls). The only APIs that could change data structures that it
> reads are
java.lang.Security.{addProvider,insertProviderAt,removeProvider},
> and possibly setProperty. So unless you are also using those APIs,
> it can't fail to be threadsafe.
This may be the case for MessageDigest but what about the general case.
Since I'm new to thread programming in Java I haven't yet come across an API
where I can demonstrate a problem but I am concerned since so much of what
O've seen in support forums discusses the "fact" (belief?) that thre API is
not, in general, thread-safe.  Are we really left with the, IMO, untenable
situation that we've got to go read the source for each J2SE/EE Class we
need to use?  Do you have any idea why Sun would not just come out and say
that, unless it's stated otherwise, the API is thread-safe?


> You could look at the implementation you're using. Of course, this doesn't
> guarantee anything about other Java API implementations.
>
....
> Determine what other APIs might change any state that the function depends
> on, and make sure that your program and any of the libraries it uses don't
> make use of those APIs without synchronization (unless the documentation
> says it is safe).

I guess my comment about reading the J2SE/EE source from above is relevant
here also!

Let me restate what I am confused and concerned about.  Here is my
reasoning:

1) Based on the large number of threads  in a variety of forums, the J2SE
API is not (believed by many to be) thread-safe, therefore...
2) There is at least one Class, call it UnsafeClass, that has at least one
method, call it UnsafeAPI() that is not thread-safe, therefore...
3) There is either a Class variable in UnsafeClass, or UnsafeAPI() has an
instance variable or there is some "external" resource such as a file,
database connection, socket, etc. that is not synchronized.  (If this is not
true then UnsafeAPI() *would be* thread-safe!).

We can ignore the case where it is an instance variable that is unprotected
because if I have an instance of UnsafeClass I can just code\
synchronize("instance of UnsafeClass") {
    UnsafeAPI();
}
and all should be well.

That leaves us with those cases where there is an unprotected Class variable
or an unprotected external resource.  I guess my question is simply, how do
I use UnsafeAPI() so that my code is thread-safe?  Code like
synchronize("instance of some Class other than UnsafeClass") {
    UnsafeAPI();
}

will not work because, while it will protect me from all threads that run
thru my code where I've been sure to always synch on "instance of some Class
other than UnsafeClass", this provides no protection from some other app
running in the JVM from just making its own call to UnsafeAPI() while my
thread is in there!

It seems like there must be something fundamental that I'm missing because
otherwise we are left with a big vulnerability in any Java app that we write
(that uses an UnsafeAPI() as I've described).

Can you shed some light on this?

Thanks for your input,
Al.
AlKoch@MyRealBoxREMOVEALLTHESECHARS.com

.