On Monday 14 March 2005 22:44, Chris Pickett wrote: > As a trivial example: it is possible to define native methods that do > the equivalent of MONITORENTER and MONITOREXIT, so that you can lock and > unlock things without using synchronized methods or blocks. If these > are allowed to be unstructured, simply because they are native, then it > seems completely pointless to let the VM enforce this rule in the first > place, since the programmer or even bytecode compiler can now easily > circumvent it. > > http://developer.novell.com/research/devnotes/1999/january/03/04.htm
I wouldn't rely too much on that document: for example it states that "there is no overhead of creating a semaphore, since all Java objects have a monitor associated with them by default", which is simply false - most VMs will only create such a monitor when it is actually needed. It's true that JNI can be used to create unbalanced monitor operations, which will clearly upset any VM which tries to take advantage of the fact that normally monitor operations will always be balanced. My first reaction is that the VM doesn't have to be able to deal with such cases - it's just another example of how JNI can be used to shoot yourself in the foot. The code example in the cited document which "cannot be written using synchronized directive without significant code reorganization" is, in my view, in urgent need of such reorganisation - it has "disaster waiting to happen" written all over it. My $0.02, Chris -- Chris Gray /k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 3 216 0369 _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
