Subj : Re: How do I use the Java API in a Thread-Safe Manner? To : comp.programming.threads From : David Hopwood Date : Thu Jun 23 2005 02:02 pm Al Koch wrote: > Hi David, > > Thanks for your reply. I have some follow on questions/comments: > >>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? It would be very bad style in Java for a constructor to make non-threadsafe use of static variables. This is a quality-of-implementation issue. You have to assess the quality of any given library before deciding whether to use it in any case (the implementation quality of different parts of the standard Java API varies considerably). >>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. There is no single answer for the general case. You use reasoning like that above for each 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 > I've seen in support forums discusses the "fact" (belief?) that thre API is > not, in general, thread-safe. Usually, you can look at the design of a set of related classes, and which of their methods are declared to be synchronized, and see whether they were *intended* to be threadsafe even if the documentation doesn't say. > 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? It's a fairly good idea to at least scan the source anyway. Of course, it's not feasible to read more than a tiny fraction of the whole source for J2SE, but if you look at a sample of the most important classes you intend to use, you might find lurking horrors -- thread-related and otherwise -- that dissuade you from using some parts of the API. > 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? It would be too much work to check whether it actually is threadsafe? Of course that supports your argument. [...] > 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!). > [...] > 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). In principle you're correct. In practice these issues affect only a small, and avoidable, proportion of the standard APIs. -- David Hopwood .