[dmd-concurrency] draft 7

[Michel Fortin]

Le 2010-02-01 à 15:30, Andrei Alexandrescu a écrit :

> Michel Fortin wrote:
>>> The program would compile successfully with the following changes
>>> to nyukNyuk and sneaky:
>>> shared(double)* nyukNyuk; // or: shared(double*) nyukNyuk; void
>>> sneaky(ref shared(double) r) { nyukNyuk = &r; }
>> How can that be safe? Leaking the reference, even as 'shared',
>> doesn't prevent someone from accessing the variable without acquiring
>> the lock. Are you suggesting that mixing atomic operations and mutex
>> synchronization for the same variable is okay? Because it's not.
> 
> You are making a good point. I thought of banning escapes altogether. After all, if someone has access to a shared data member and the synchronized method assumes it can temporarily optimize access to that member as if it's unshared, things can get messed up.
> 
> On the other hand, if you hand out a reference to a member, you're kind of setting yourself up for surprises. Far as the type system is concerned, it's doing the right thing.


Escaping a value, even as 'shared', breaks the synchronization guaranties. If the type system cares about synchronization, then it should not allow a variable to escape.


> One related thought: a long time ago, Walter, Bartosz and I briefly coquetted with the idea of using "scope" to denote an unescaping parameter:
> 
> void print(scope int[] array) { ... }
> 
> With this signature print guarantees it won't escape anything in array. Then synchronized functions can pass (addresses of) members to functions like print.

That's a simple solution. It's limited, since you can't implement something like swap(ref int[], ref int[]) and thus not sorting algorithm, but it's better than nothing.



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