Checked exceptions within Block<T>

[Gregg Wonderly]

On 1/18/2013 12:27 PM, Remi Forax wrote:
> On 01/16/2013 10:32 PM, Neal Gafter wrote:
>> On Wed, Jan 16, 2013 at 10:24 AM, Remi Forax <forax at univ-mlv.fr
>> <mailto:forax at univ-mlv.fr>> wrote:
>>
>>      The current lambda spec doesn't allow to capture variable, only
>>      value can be captured.
>>
>>
>> The current spec allows you to use the name of a variable inside the
>> lambda after the scope in which the variable was declared has exited.
>>   The meaning is that it gives the value last (and only, in the current
>> spec) assigned to that variable.  You can't "capture a value" because
>> a value does not have a name.  Allowing capture of mutable variables
>> simply removes the parenthetical restriction in my description.
> you can capture the value of the variable when you do the lambda conversion.
>
>>          There is no reason for such lambdas to be "biased to the
>>          current thread".
>>
>>
>>      There is a good reason, avoid to have to declare volatile local
>>      variable.
>>      And if you can transfer ownership  I don't see the problem.
>>
>>
>> For the same reason, you should be able to declare instances of
>> classes "biased to the current thread" so that you can "avoid to have
>> to declare volatile fields".  Unless you're considering that for
>> classes, I don't see why you'd consider that for lambdas.
> The current abstraction is fields are spaces in shared memory (the heap)
> and local variable are thread local spaces (the stack). That why I think
> that stack variable captured by a lambda should be thread local (that
> may be promoted to shared space but explicitly).
>
> Rémi

What should happen here?  func's argument should be the same 'a' that r1 
manipulated yes?  What about visibility across threads?  We still need happens 
before on 'a' if r1 and r2 might be performed in separate threads, correct?  
Would there be any reason to consider that a lambda implicitly includes a 
happens before for any externally resolved variable?  I.e. a fence on entry and 
exit to facilitate automatic inter-Thread visibility control?   Since lambdas 
provide the "visibility" of the "communicating" variables into and out of the 
lambda, as a method does, I suppose there is no desire to "magically" provide 
behaviors like this.  Is there any thought about how to signify such behavior so 
that there could be a "soft" "synchronized" designation for lambdas to try and 
start refining and "fixing" the whole visibility issue?

Runnable r1, r2;
{
     int a = 0;
     r1 = () -> { a = 1; };
     r2 = () -> { func(a); };

     if( other ) {
    	 r1 = () -> { a = 2; };
     }
}
r1.run();
new Thread( r2 ).start();

Gregg Wonderly