On Jun 3, 2012, at 12:29 PM, deadalnix wrote:
> 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.
There is a bit of cleverness in there.
