On Thu, 14 May 2009 13:12:46 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Robert Jacques wrote:
>> On Thu, 14 May 2009 02:13:37 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> Robert Jacques wrote:
>>>> I agree for POD, but what classes where the synchronization is encapsulated behind a virtual function call?
>>>
>>> synchronization can make a shared reference "tail shared".
>>  I agree, but that doesn't seem answer my question. Put another way, if I have an interface I which is implemented by both a thread local class L and a shared class S, then does some function F need to know about whether the implementor of I is S or L?
>
> Since a reference to thread local cannot be implicitly cast to shared, then this scenario cannot happen - i.e. a shared function is not covariant with an unshared one.
>> P.S. There will obviously be some interfaces S can't implement, but that a separate issue.
>>
>>>> Also, does this mean 'scope' as a type is going away?
>>>
>>> Scope never was a type, it's a storage class.
>>  Sorry for the confusion of terminology. However, you talk blog about using the 'scope' keyword to support escape analysis, ettc. i.e. 'scope' would become the 'const' of the shared-thread local-stack storage type system. Is this still the plan?
>
> I'm not sure what you mean by that.

I'm asking about the use of scope you blogged about:

http://dobbscodetalk.com/index.php?option=com_myblog&show=Escape-Analysis.html&Itemid=29

[...]

For D, we are looking at a design that creates a parameter storage class called scope:

T foo(scope int* p);

The presence of scope means that the function will not allow the parameter, or anything reachable through that parameter, to escape from the scope of the function. The scope storage class can be applied to the parameters or the 'this' reference (for member functions). Initially, this will be a promise by the implementor of foo(), but it should be entirely possible for the compiler to perform escape analysis using data flow analysis techniques on the implementation of foo() to ensure it. The caller of the function will know that a reference to a local variable can be safely passed as a scope parameter. A million line program can be automatically verified as being free of escaping reference bugs.

Robert Jacques wrote:
>>>  Sorry for the confusion of terminology. However, you talk blog about using the 'scope' keyword to support escape analysis, ettc. i.e. 'scope' would become the 'const' of the shared-thread local-stack storage type system. Is this still the plan?
>>
>> I'm not sure what you mean by that.
> 
> I'm asking about the use of scope you blogged about:
> 
> http://dobbscodetalk.com/index.php?option=com_myblog&show=Escape-Analysis.html&Itemid=29 
> 
> 
> [...]
> 
> For D, we are looking at a design that creates a parameter storage class called scope:
> 
> T foo(scope int* p);
> 
> The presence of scope means that the function will not allow the parameter, or anything reachable through that parameter, to escape from the scope of the function. The scope storage class can be applied to the parameters or the 'this' reference (for member functions). Initially, this will be a promise by the implementor of foo(), but it should be entirely possible for the compiler to perform escape analysis using data flow analysis techniques on the implementation of foo() to ensure it. The caller of the function will know that a reference to a local variable can be safely passed as a scope parameter. A million line program can be automatically verified as being free of escaping reference bugs.

We've talked about it, but am unsure as to whether it will work or not.

Walter Bright Wrote:

> Matt wrote:
> 
> Shared data becomes unshared for the duration of a lock on it.

Is that a statement of fact? Or is it just speculation leading to the issues below? Even if this was changed to "scope unshared", that still is really hairy since scope is a storage class.

> The problem with this is:
> 
> 1. determining that there are no other shared references into that data.
> 
> 2. determining that the code operating on that data doesn't squirrel away a thread local reference to it.
> 
> Currently, Bartosz is working on these problems. There is no solution yet other than using an (unsafe) cast and relying on the user not to screw it up.

His last blog implied he was further. I thought the recent shift to use TLS and shared inside dmd was because a design had been worked out. Without that, D hardly helps writing correct multi-threaded code :( It may be that I'm being overly pessimistic...

> >> Can you imagine two threads trying to sort the same array?
> > Not at the same time, but yes.
> 
> That's why there's no way one would do this with simply shared data. Locks would be needed, too.
> 

Jason House wrote:
> His last blog implied he was further. I thought the recent shift to
> use TLS and shared inside dmd was because a design had been worked
> out. Without that, D hardly helps writing correct multi-threaded code
> :( It may be that I'm being overly pessimistic...

Even if D goes *no further* with shared than where it is now, it still helps a *lot* in writing correct multi-threaded code.

It does this by making the points where threads communicate obvious, instead of inadvertent and hidden.