[dmd-concurrency] there is no escape

[Michel Fortin]

Le 2010-02-04 à 2:03, Andrei Alexandrescu a écrit :

> It looks like there is agreement that there is no escaping of any reference to an object's fields from within a method of a synchronized class. Inside a method of a synchronized class, effectively all members are transitively scoped.

Great! :-)


> This is quite restrictive, but it's the right thing to do with the expressive abilities we now have. I think it's possible D3 will add some capabilities, but for the time being it looks this is it.
> 
> One possible improvement is, as discussed, defining "scope" as a storage class for function parameters. I now remember a number of additional difficulties related to that when Walter and I discussed things a few months ago. One issue was that the storage class has to be transitive, which makes it an odd beast. Making scope a qualifier would be the right thing to do, but then too many qualifiers make the language quite baroque.

Yes, the storage class needs to be transitive. But I think you're overestimating the language complexity it introduces by a small bit. It makes not sense to write 'scope(int)[]', the only thing you may want with scope is to qualify the hole variable. Perhaps it makes sense to implement it as a type qualifier, but I'm not so sure, and it doesn't need to be exposed like that in the syntax. Scope should be seen as a restriction attached to the non-shared part of a variable.

'scope' can get much more complicated if we want to use it express precisely the lifetime of each stack frame to allow safe inter-frame assignments, but limiting its use to denote the owner of references to synchronized members should make it pretty much on-par to implementing it for access to member within a method of a synchronized class.


> As we already knew, shared/synchronized limit quite drastically the range of lock-based designs without casts. Fortunately, using a class reference member inside a synchronized object will be possible because... well I'll explain in the text.


I'm curious to see what it'll look like. I predict it'll make the language look quite incomplete if you have to cast your way around at each function call.

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