Thanks, Miguel. I've found two instances in the 10.2 code where this was causing null pointer errors (one in Isosurface and one in Normix). I've fixed it in 10.x.10, although I think I still have to add synchronization to the methods that create the trouble-causing arrays.
If I have this right, the problem is that you cannot: static int[] myarray = new int[128]; without first checking to see if the array already exists, and that check should be within a synched method. Yes? Do you want to do it yourself in 10.2/10.3? I guess I'd appreciate it if you took a look, since you know that g3d code a lot better than I do, and that seems to be where there problem is mainly. I looked at Colix, but I think those are all carefully synched already. But there may be other places, like the geodesics, where that isn't the case. Could you look? Bob ps. I just got isosurface solvent 1.2 to work. Oh, how beautious! The code is so miniscule it almost hurts. (Just a few short methods and some careful geometry.) Knowing how complicated this was in Dots.java..... I'll commit it and post a demo soon. Miguel wrote: >>Miguel, Egon, other Java pros, I need your help: >> >>Is it possible that when you use static variables in an applet then, >>when there are multiple applets on a page all loading at the same >>time, they share each other's variables? > > > Yes, the definition of a static variable is that all instances share the > same variable. > > Put another way, the variable is associated with the class, not with the > instance. > > The JVM only loads a class once, and it is shared across multiple threads > within the same 'process' and across multiple 'processes'. > > >>-- i.e. TRASH each other's >>variables? > > > The *purpose* of static class variables is to provide a mechanism for > different instance in potentially different threads to *communicate* with > each other in a coordinated (synchronized) fashion. > > If the usage of the variables is not coordinated then they will TRASH each > other. > > >>I've got a page with 5 isosurfaces, one in each of 5 applets, and each >>time I load it at least one of them is totally trashed -- but trashed >>in a DIFFERENT way seemingly randomly each time I load. > > > OK > > >>I realize now it is because I assigned "static" to arrays of objects >>that really aren't static. > > > Then that is your problem. Good job in identifying this. > > Developers should not use 'static' variables unless they understand the > implications ... and the implications can be complicated in a > multi-threaded world. > > >>If the answer to this question is YES, then could this explain some of >>the odd null pointer errors that have arisen in the colix/normix area >>recently? >> >>For example, I see in Colix.java: >> >>private static int[] argbs = new int[128]; >> >>Now, maybe the "private" takes care of this, but if some other applet >>had assigned values to "argbs", wouldn't this then cause a problem? > > > The argbs variable is 'static' by design. > > In cases where there are multiple instances of the applet, I thought that > there was value if having them share the same argb->colix mapping. > > Write access to the 'argbs' array is funnelled through a 'synchronized' > procedure to ensure that only one thread at a time can update the 'argbs' > array. > > I am not saying that there are no bugs in the Colix code ... but it was > made 'static' by design and the code has essentially remained unchanged > for 3 years ... so it is not the first place that I would look. > > >>I'm reminded of the day I saw a button control on one page rotate the >>model on another..... > > > Yes, I agree that this sounds like a related issue. Multiple applets with > the same name being active at the same time. > > >>Is this an issue we should look into? > > > As with all bugs, it is best to avoid them in the first place. > > Bugs that change behavior because of improper synchronization between > threads/processes fall under the general heading of 'race conditions'. > These bugs are generally the worst to track down. > > Multi-threading stuff is very complicated. Many have complained that the > threading support built into Java makes inter-thread communication too > easy ... and therefore too easy to introduce race conditions. Java > provides low-level synchronization primitives, but one usually must build > their own infrastructure to support robust thread-synchronized access to > data structures. > > Developers should not introduce static member variables without > > I used some static+synchronized access to some variables in a couple of > places in the code ... like Colix. I made a conscious decision to do so > because I thought that the associated data structures could be safely > shared across threads/processes. > > > Miguel > > > > _______________________________________________ > Jmol-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-developers -- Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:[EMAIL PROTECTED] http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
