Re: Safety of running and stopping dynamically loaded code


Doug Lea (dl@cs.oswego.edu)
Fri, 19 Mar 1999 19:13:32 -0500 (EST)


> synchronized(java.lang.Math.class) { > absolutelypositivelymustcomplete { > for (;;) { > try { Thread.sleep(1000); } catch (Throwable t) {} > } > } > } > > // for absolutelypositivelymustcomplete, substitute David's catch/respawn > // code, or its moral equivalent > > Now, just synchronizing on a class object by itself isn't necessarily fatal. > I can synchronize on, say, java.lang.VerifyError.class all day long, and the > only person who'd notice is someone else who's as silly as I am. Math.class > is different, because Math has a static synchronized method. By holding > the lock, I prevent anyone else from computing random numbers. Well, the funny thing about this particular example is that I can see no reason that Math.random() needs to be class-lock synchronized. The underlying java.util.Random object internally synchs anyway. Even the lazy creation in Math.random is OK without synch, although it takes a subtle argument to show this is so. In any case, the fact that any code can externally grab the lock for any object (including class objects) is clearly a design flaw in Java. Lack of programmer-specified protection against external locking is inconsistent with every other construct in the language. The main consequence is that it is humanly impossible to protect against hostile lockups. You can take steps to decrease likelihood, but I think that any attempt to fully protect a java framework against hostile lockups is unlikely to work -- it is a losing proposition to try to reason through what might happen if some code grabbed locks on any/all potentially visible objects in a running application. So, personally, I just don't worry about it. -- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/ ---------------------------------------------------------------------------- To unsubscribe (or other requests) mailto:majordomo@media.mit.edu List archives, FAQ, member list, etc. http://gee.cs.oswego.edu/dl/javares/



This archive was generated by hypermail 2.0b3 on Fri Mar 19 1999 - 19:16:18 EST