Bill Foote (Bill.Foote@Eng.Sun.COM)
Fri, 19 Mar 1999 19:21:25 -0800 (PST)
Peter Seibel wrote: > >>>>> "Doug" == Doug Lea <dl@cs.oswego.edu> writes: > > >> 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. > > Doug> Well, the funny thing about this particular example is that > Doug> I can see no reason that Math.random() needs to be > Doug> class-lock synchronized. The underlying java.util.Random > Doug> object internally synchs anyway. Even the lazy creation in > Doug> Math.random is OK without synch, although it takes a subtle > Doug> argument to show this is so. > > Doug> In any case, the fact that any code can externally grab the > Doug> lock for any object (including class objects) is clearly a > Doug> design flaw in Java. Lack of programmer-specified protection > Doug> against external locking is inconsistent with every other > Doug> construct in the language. > > Well, you could just pretend that synchronized methods don't exist; > instead of: > > class X { > synchronized void foo() {} > } > > do: > > class X { > private Object lock = new Object(); > void foo() { synchronized(lock) {} } > } > > No? > > -Peter Precisely. In the given example, you stick "static" in front of everything, but it's the same deal. So yes, two different clients that both try to lock on Math.class can interfere with eachother, but that's their own fault. If the bad guy, by acquiring the lock on Math.class, can cause innocent code in a different "process" to fail, that's badness.
This archive was generated by hypermail 2.0b3 on Sat Mar 20 1999 - 07:38:50 EST