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

[Michel Fortin]

Le 2010-01-04 à 23:57, Andrei Alexandrescu a écrit :

> Sean's code has an error: mutateA takes an A (as opposed to a shared A) so no synchronization is assumed or necessary.
> 
> Again: non-shared objects _are_ thread-local objects.
> 
> Andrei

Indeed, he probably meant the argument as shared. That doesn't really change my point however.

If we had synchronized function arguments, locking could be done more efficiently at the call site, where you know better what's already locked. That was your own reasoning for suggesting to Walter to acquire the lock at the call site for synchronized member functions, so I'm just generalizing it a bit more.



> Michel Fortin wrote:
>> Le 2010-01-04 à 22:49, Sean Kelly a écrit :
>>>   class A {
>>>       void fnA() synchronized { fnB(); } // 1
>>>       private void fnB() synchronized {}
>>>   }
>>> 
>>>   void mutateA( A val ) {
>>>       val.fnB(); // 2
>>>   }
>>> 
>>> At 1, the compiler can easily tell that the lock is already held so it doesn't acquire the lock again.  At 2 the lock is (probably) not held, so it's acquired again.
>> To avoid that "lock is probably not held" situation, we could allow the standalone function to be declared like this:
>> 	void mutateA(synchronized A val) {
>> 	    val.fnB();
>> 	}
>> Now 'val' can be locked at the call site, if necessary.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/