This is actually a somewhat unfortunate "feature". Had this not been in
place, I could have just used custom bytecodes to perform the lock magic
that I ended up using Unsafe for (I'm the guy that wrote JBoss Modules,
i.e. apparently the one usage "in the wild" of these methods).
The restriction is kind of pointless anyway as it's not really "unsafe",
it just can lead to buggy code. And given that the only way to utilize
those two particular codes (monitorenter/monitorexit) from Java is via
"synchronized", which is necessarily balanced, the restriction seems to
impose needless limitation.
On 02/27/2014 07:56 AM, Vitaly Davidovich wrote:
Right, there's no such guarantee/requirement. JVMS mentions that
implementations are permitted to enforce balance (called structured locking
there) but not required:
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10
Thanks
Sent from my phone
On Feb 27, 2014 8:40 AM, "Jeroen Frijters" <jer...@sumatra.nl> wrote:
David Holmes wrote:
I don't think this is workable. Exposing a monitor as Lock would allow
you to break the guarantees/requirements involving balanced-locking for
monitors.
Where are these guarantees/requirements documented?
Regards,
Jeroen
--
- DML
