Le 01/06/2012 22:55, Sean Kelly a écrit :
On Jun 1, 2012, at 5:26 AM, deadalnix wrote:
The main drawback is the same as opApply : return (and break/continue but it is
less relevant for opSynchronized). Solution to this problem have been proposed
in the past using compiler and stack magic.
It open door for stuff like :
ReadWriteLock rw;
synchronized(rw.read) {
}
synchronized(rw.write) {
}
Opens the door? This works today exactly as outlined above. Or am I missing a
part of your argument?
And many types of lock : spin lock, interprocesses locks, semaphores, . . . And
all can be used with the synchronized syntax, and without exposing locking and
unlocking primitives.
All works today.
Unless you do some monitor magic, it doesn't.
