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

[deadalnix]

Le 04/06/2012 02:21, Andrew Wiley a écrit :
> On Sun, Jun 3, 2012 at 5:13 PM, deadalnix <deadalnix at gmail.com
> <mailto:deadalnix at gmail.com>> wrote:
>
>     Le 04/06/2012 02:03, Andrew Wiley a écrit :
>
>         On Sun, Jun 3, 2012 at 4:39 PM, deadalnix <deadalnix at gmail.com
>         <mailto:deadalnix at gmail.com>
>
>         <mailto: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>>
>         <mailto: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.
>
>
>     I meant where is the code ?
>
> My apologies, it's actually ReadWriteMutex:
> http://dlang.org/phobos/core_sync_rwmutex.html

Which does use monitor magic.