On 04-06-2012 02:03, Andrew Wiley wrote:
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.
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 [email protected] http://lycus.org
