Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

[Dr Heinz M. Kabutz]

Plus, monitors can get optimized beautifully when there is no 
contention, although that falls away for the code that uses 
monitorEnter/monitorExit calls directly as far as I could tell.

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Oracle Java Champion 2005-2013
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz



David M. Lloyd wrote:
> A "Monitors" class could possibly be introduced which simply has three 
> (intrinsic) static methods: void lock(Object obj), void unlock(Object 
> obj), boolean tryLock(Object obj).
>
> Could even add a void lockInterruptibly(Object obj) throws 
> InterruptedException.
>
> Why not?  Monitors are not going anywhere, and they're considerably 
> lighter than ReentrantLock in terms of memory usage and allocations in 
> the (pretty common) case where you only need zero or one conditions. 
> Avoiding something like this out of loyalty to new APIs is probably 
> pretty misguided.
>
> On 02/27/2014 08:51 AM, Dr Heinz M. Kabutz wrote:
>> I have never used this "in the wild", but rather have moved over to the
>> ReentrantLock when I needed that particular functionality.
>>
>> However, I do see a place for this ability.  As I wrote in here:
>> http://www.javaspecialists.eu/archive/Issue194.html - sometimes you need
>> to modify code that is already using a particular locking mechanism.  To
>> then redo everything with ReentrantLock can introduce errors.
>>
>> If I had a say, I would vote to either keep that method in Unsafe (which
>> is where I think it belongs) or provide an alternative way to make the
>> tryMonitorEnter() mechanism available to those that might end up needing
>> it.
>>
>> Since I bought my Suzuki Jimny 7 years ago, I have not needed my spare
>> wheel even once.  So yeah, I could take it off and drive around without
>> it.  But chances are, the day after I take it off, I will need it.
>>
>> tryMonitorEnter() does no harm and it is out of reach of most 
>> programmers.
>>
>> Regards
>>
>> Heinz
>
>