[Swift-devel] Changes to array closing semantics?

[Tim Armstrong]

Mihael and I had a brief exchange off-list.  I think it sounds that the
situation is that we agree almost entirely on the intended semantics, but
that the implementations differ in how close they are to the ideal
behaviour.  It seems like the main points of difference are:

   - There are differences in whether deadlocks/other errors are detected
   at compile time or run time, and the quality of the error messages/other
   diagnostics.  E.g. both eventually detect runtime deadlocks, but Swift/K
   prints more info about the cycle.  Swift/T I think detects more problems at
   compile time to do with partial/total assignment of arrays.
   - Swift/T's bookkeeping for array closing operates at the level of
   individual statements so can close arrays earlier.  This avoids the Swift/K
   deadlocks where there is a dependency loop involving a scope exit.  This
   means that Swift/K deadlocks in cases where Swift/T wouldn't, but otherwise
   the behaviour is the same.
   - Swift/T currently doesn't start a foreach loop executing until the
   array is closed.  This is a known limitation we intend to fix.  Swift/K has
   already got a fix for this.

- Tim

On Wed, Nov 21, 2012 at 6:50 PM, Tim Armstrong <tim.g.armstrong at gmail.com>wrote:

> I had a couple of comments.
>
> I think the difference between Swift/K and Swift/T is mostly
> implementation rather than to do with restrictions on semantics - there
> weren't really any decisions I made where I was restricting something in
> order to avoid potential deadlocks.   (There might be some differences
> where we're better/worse at detecting deadlocks at compile time, but that's
> a separate issue).
>
> I don't see why this example necessarily deadlocks - it doesn't in Swift/T
> since there isn't a true data dependence loop.
>
>
> foreach i in [0:10] {
>   a[i] = 1;
>   f(a);
> }
>
> In Swift/T it does the same thing as:
>
> foreach i in [0:10] {
>   a[i] = 1;
> }
> foreach i in [0:10] {
>   f(a);
> }
> I understand in Swift/K there is some sort of dependence loop ( scope
> exiting <- f(a) executing <- a being closed <- scope exiting).  In Swift/T
> the statements a[i] = 1 and f(a) are forked off separately, then the
> writers count is decremented after each insertion succeeds.  There isn't an
> explicit runtime event corresponding to all statements in a block finishing.
>
> - Tim
>
>
> On Wed, Nov 21, 2012 at 3:51 PM, Mihael Hategan <hategan at mcs.anl.gov>wrote:
>
>> On Wed, 2012-11-21 at 12:12 -0700, Justin M Wozniak wrote:
>>
>> > I don't think this is currently an issue in the Swift/T implementation
>> > but I can check.  In Swift/T, we have the restriction that you cannot
>> > assign to an array A=f() and also do piecemeal assignments A[i]=g() .
>> > We do track potential write accesses to arrays to keep them open until
>> > there are no more possible writes.
>> >
>> > http://www.mcs.anl.gov/exm/local/guides/swift.html#_arrays
>>
>> That restriction should also be in swift/k, and I don't think it is.
>>
>> There is a problem with the current implementation. It fails to properly
>> execute the following code:
>>
>> int[] a;
>>
>> if (true) {
>>   if (true) {
>>     a[0] = 1;
>>   }
>>   else {
>>    a[0] = 2;
>>   }
>>   f(a);
>> }
>>
>> This is because a is closed in the scope in which it's declared, but
>> that won't be done until f(a) completes, which it can't because a is not
>> closed. That needs fixing. An additional complexity is that the
>> following should also be allowed and function correctly:
>>
>> int[] a;
>>
>> if (true) {
>>   if (condition) {
>>     a[0] = 1;
>>   }
>>   f(a);
>> }
>>
>>
>> There's also the issue of:
>> int[] a;
>>
>> foreach i in [0:10] {
>>   a[i] = 1;
>>   f(a);
>> }
>>
>> That shouldn't be allowed. It is, and it leads to a deadlock.
>>
>> There are some subtleties:
>>
>> int[] a;
>> if (true) {
>>   foreach i in [0:10] {
>>     if (true) {
>>       a[i] = 0;
>>     }
>>     else {
>>       a[i] = 1;
>>     }
>>   }
>>   f(a);
>> }
>>
>> Closing of a can only happen after the foreach is done.
>>
>> All these cases need to be correctly handled by the compiler, and I
>> think none of them are.
>>
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121121/5c691848/attachment.html>