synchronized (this[.classinfo]) in druntime and phobos
Andrew Wiley
wiley.andrew.j at gmail.com
Sun Jun 3 17:03:31 PDT 2012
On Sun, Jun 3, 2012 at 4:39 PM, deadalnix <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>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120603/2edd2f1a/attachment.html>
More information about the Digitalmars-d
mailing list