February 03, 2010 [dmd-concurrency] there is no escape | ||||
---|---|---|---|---|
| ||||
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. 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. 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 continue to believe this is the right bet to make, but I expect push back from experienced lock-based programmers. Andrei |
February 04, 2010 [dmd-concurrency] there is no escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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/ |
Copyright © 1999-2021 by the D Language Foundation