[dmd-concurrency] draft 7

[Robert Jacques]

On Mon, 01 Feb 2010 16:10:06 -0500, Andrei Alexandrescu  
<andrei at erdani.com> wrote:

> Robert Jacques wrote:
>> On Mon, 01 Feb 2010 15:30:47 -0500, Andrei Alexandrescu  
>> <andrei at erdani.com> wrote:
>>> 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.
>>  What's difficult to implement specifically? Full escape analysis is  
>> difficult, but you can provide the same guarantees by being a bit  
>> conservative.
>
> Nah, it's the details that are difficult:
>
> * most functions do take scope parameters, so probably @escaping should  
> be the explicit attribute
>
> * interaction of scope with templates
>
> * what annotation do you use for saying that "this" is scoped, e.g.
>
> class A {
>     void foo() scope { ... }
> }
>
> (and in fact most of the time this is scoped, so again @escaping...)
>
> * figuring out how all of this aggravation will be received by users  
> already displeased by the size of the language
>

Ah, thanks.