On Sun, Jun 3, 2012 at 4:39 PM, deadalnix <[email protected]> wrote:
> Le 03/06/2012 21:40, Andrew Wiley a écrit : > >> On Sun, Jun 3, 2012 at 12:29 PM, deadalnix <[email protected] >> <mailto:[email protected]>> 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.
