[dmd-concurrency] draft 7

Andrei Alexandrescu andrei at erdani.com
Mon Feb 1 12:30:47 PST 2010


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.

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.

It's not an easy feature to implement though.


Andrei


More information about the dmd-concurrency mailing list