Missing const feature? Having a thread own the read/write privilege

Jason House jason.james.house at gmail.com
Mon Jun 25 04:48:50 PDT 2007


Frits van Bommel wrote:
> Jason House wrote:
>> For single-threaded applications, I believe an implicit cast to 
>> _scope_ invariant is ok and *should* be allowed implicitly.
> 
> I believe you are wrong about that.
> 
>> If I call a function, it's guaranteed that the variable won't get 
>> modified by anything else while the function is executing.
> 
> No it isn't:
> ---
> import std.stdio;
> 
> class Foo { int x; }
> 
> void bar(scope /* invariant */ Foo foo, void delegate() dg) {
>     writefln(foo.x);
>     dg();
>     writefln(foo.x);
> }
> 
> void main() {
>     Foo f = new Foo;
>     f.x = 3;
>     bar(f, { f.x = 4; } );
> }
> ---
 >
> Your suggestion would allow creation of a modifiable invariant reference 
> without requiring a cast.
> Note that a similar example can also be constructing without passing a 
> delegate; a normal function call in bar() and a global mutable reference 
> would be just as effective.


Global variables and variables should definitely not be defaulted to 
this behavior.  Long lived functions such as main and run are far more 
likely to have local variables that shouldn't follow this pattern.

You've convinced me that this behavior by default for most variables is 
probably not a good idea, but I'm not yet convinced that it isn't a good 
language feature to have.


> It's only safe to allow implicitly casts to invariant when the compiler 
> can determine that no mutable references exist.
> It may also be safe to implicitly cast to scope invariant if the 
> compiler can determine that no mutable references will be accessible (or 
> at least that they won't be used to write to it) during the lifetime of 
> the scope invariant reference.


It's been argued that the compiler and programmer should cooperate.  If 
the programmer explicitly declares it as such, the compiler should then 
only complain if it can disprove it.


> The latter (no mutating accesses during lifetime) is probably pretty 
> hard to determine automatically in the general case unless you know the 
> former (no mutable refs exist), especially as you noted on 
> multithreading operating systems. (And I don't think the programming 
> language should change just because you start using threads)

I started with a single-threaded description to try and get the basics 
down.  If the basics can be worked out for single threaded cases, then 
it'd merit the more complex handling for multi-threaded.

I assume that in many cases, variables are only modified by a single thread.



More information about the Digitalmars-d mailing list