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
--
- DML
