[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unstructured locking bug
From: |
Chris Gray |
Subject: |
Re: Unstructured locking bug |
Date: |
Tue, 15 Mar 2005 00:07:57 +0100 |
User-agent: |
KMail/1.5.4 |
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
Re: Unstructured locking bug, Etienne Gagnon, 2005/03/14
RE: Unstructured locking bug, David Holmes, 2005/03/14