Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods
David M. Lloyd
david.lloyd at redhat.com
Thu Feb 27 14:24:36 UTC 2014
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:
> Sent from my phone
> On Feb 27, 2014 8:40 AM, "Jeroen Frijters" <jeroen at 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
>> Where are these guarantees/requirements documented?
More information about the core-libs-dev