On 03/03/2014 09:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might as well
just delete most of the JDK, ReentrantLock included, since it suffers
from the exact same potential problem. The difference is that monitors
have a simple API in the form of synchronized that people were in the
past and would continue to be free (and recommended) to use.
We should not introduce anything that allows something that was
guaranteed to be safe by the language, to become unsafe.
Define 'safe'. Because I don't think it's unsafe, any more than
unpaired lock/unlock are. There is no uninitialized memory being
accessed, no way to bypass security checks, no way to manipulate memory
directly, etc. I find this argument to be particularly weak without
specific cases. As far as I can tell, the language doesn't make it
safe, it makes it *convenient*, and that's a big distinction.
There are two cases I can see that are potentially problematic: extra
acquires, and extra releases.
The risk of extra acquires is that the thread might exit while still
holding the lock, leaving it locked forever. However, just parking a
thread indefinitely (via various means) within a synchronized block is
equally unsafe.
The risk of extra releases is that you'll hit IllegalMonitorState
exceptions and thread-safety/publication problems. But a user can make
this same mistake today with locks. The difference is, that in most
cases people would choose the convenience of synchronized unless there
is a specific reason for it, making this problem far less likely than
the corresponding locks case.
--
- DML
