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

deadalnix deadalnix at gmail.com
Sun Jun 3 16:39:59 PDT 2012


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>> 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 ?


More information about the Digitalmars-d mailing list