[dmd-concurrency] synchronized, shared, and regular methods inside the same class

Sean Kelly sean at invisibleduck.org
Thu Jan 7 06:47:34 PST 2010


I suppose you're right.  The lock would be acquired inside the  
function, so no need to make that a part of the delegate type.  As for  
changing shared delegates, you're right that it's the same as simple  
assignment for an array.  Oh well.

Sent from my iPhone

On Jan 7, 2010, at 4:12 AM, Michel Fortin <michel.fortin at michelf.com>  
wrote:

> Le 2010-01-06 à 14:52, Sean Kelly a écrit :
>
>> class MyClass {
>>   void fnA() synchronized {}
>>   void fnB() shared {}
>> }
>>
>> auto x = new MyClass;
>> auto y = &x.fnA;
>> auto z = &x.fnB;
>>
>> I'd guess that the type of y is "delegate() synchronized" and the  
>> type of z is "delegate() shared"? Assuming this is right, then it  
>> seems like the mutex would be locked when y is called, and the  
>> appropriate thing would happen when z is called as well.
>
> It doesn't make much sense to have a different type for delegates to  
> shared function. Shared is the type of the "this" pointer, which is  
> nicely opaquely stored in the delegate itself, propagating shared  
> for the "this" pointer as part of the delegate (or const, or  
> immutable) doesn't serve any purpose.
>
> I'd be tempted to say the same about synchronized, but if the call  
> site is responsible for locking the mutex it might be needed.
>
>
>> That leaves arrays, which are a tad more complicated because they  
>> have both a length and a pointer field.
>
> It's no different for a delegate which has a function pointer and a  
> context pointer.
>
>
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>
>
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency


More information about the dmd-concurrency mailing list