Le 03/06/2012 21:40, Andrew Wiley a écrit :

On Sun, Jun 3, 2012 at 12:29 PM, deadalnix <deadalnix@gmail.com

<mailto:deadalnix@gmail.com>> 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.

Yes, it does.
-----
class Something {
    private:
        ReadWriteLock _rw;
    public:
        this() {
            _rw = new ReadWriteLock();
        }
        void doSomething() shared {
            synchronized(_rw.read) {
                // do things
            }
        }
}
-----
I've used this pattern in code. There might be some casting required
because the core synchronization primitives haven't been updated to use
shared yet.

And where is that ReadWriteLock ?