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.
