synchronized (this[.classinfo]) in druntime and phobos

[Alex Rønne Petersen]

On 04-06-2012 02:03, Andrew Wiley wrote:
> On Sun, Jun 3, 2012 at 4:39 PM, deadalnix <deadalnix at gmail.com
> <mailto:deadalnix at gmail.com>> wrote:
>
>     Le 03/06/2012 21:40, Andrew Wiley a écrit :
>
>         On Sun, Jun 3, 2012 at 12:29 PM, deadalnix <deadalnix at gmail.com
>         <mailto:deadalnix at gmail.com>
>         <mailto:deadalnix at gmail.com <mailto:deadalnix at 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 ?
>
> On the GC heap, just like the Monitor object pointed to by __monitor if
> you mark a method or class as synchronized.

The monitor in obj.__monitor is actually allocated on the native C heap, 
and, in some cases, leaked... one of the many reasons I want it gone.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org