On Sun, Feb 24, 2002 at 08:27:43PM +0100, Niklas Mehner wrote: > Oskar Sandberg wrote: > > >"PThread-71" prio=1 tid=0x0x8292a48 nid=0x1a04 runnable > >[4f843000..4f84386c] > > at freenet.crypt.SHA1.update(SHA1.java:260) > > - waiting to lock <0x44a53d30> (a freenet.crypt.SHA1) > > > ... > > > > > at freenet.crypt.CryptoKey.fingerprint(CryptoKey.java:71) > > - locked <0x44a53d30> (a freenet.crypt.SHA1) > > > >This has to be a JVM bug, doesn't it? > > > Why ? The thread is not blocked, but is running. > I guess "waiting to lock" just means that the thread is in the > synchronisation code.
Well, I didn't tell the full story. The user was reporting a runaway thread count, and the stacktrace also showed a large number of threads (>25) waiting on the monitor for the RoutingTable which that thread held. Since I have never seen any threads waiting on the routing table otherwise, I think that it had in indeed locked there for some time. > But I find it kind of strange that the update method is synchronized at all, > because it is called for each byte and synchronization isn't that fast. > This probably > should (and perhaps is already) done on a higher level. Tavin and I agreed, and removed the synchronize on that method under the assumption that any code where many threads feed the same digest is broken. As it turned out, there is one time when it is completely ok for several threads to be feeding the same digest: the random number generator. So I think it is Scott who gets a slap on the fingers here, for without documentation synchronizing a single method in the SHA1 class to suit his high level code. I have now added the necessary synchronization in Yarrow.java instead. However, I still think that the JVM in question was broken. -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
