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