Re: Unstructured locking bug

[Chris Gray]

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/
address@hidden                         +32 3 216 0369