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:<br>
<ul><li>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.<br>
</li><li>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.<br>
</li><li>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.<br></li></ul>- Tim<br><br><div class="gmail_quote">
On Wed, Nov 21, 2012 at 6:50 PM, Tim Armstrong <span dir="ltr"><<a href="mailto:tim.g.armstrong@gmail.com" target="_blank">tim.g.armstrong@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I had a couple of comments.<br><br>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). <br>
<br>I don't see why this example necessarily deadlocks - it doesn't in Swift/T since there isn't a true data dependence loop.<div class="im"><br><br>
foreach i in [0:10] {<br>
a[i] = 1;<br>
f(a);<br>
}<br><br></div>In Swift/T it does the same thing as:<div class="im"><br>foreach i in [0:10] {<br>
a[i] = 1;<br>} <br>foreach i in [0:10] {<br></div>
f(a);<br>
}<br>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.<span class="HOEnZb"><font color="#888888"><br>
<br>- Tim</font></span><div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Wed, Nov 21, 2012 at 3:51 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, 2012-11-21 at 12:12 -0700, Justin M Wozniak wrote:<br>
<br>
> I don't think this is currently an issue in the Swift/T implementation<br>
> but I can check. In Swift/T, we have the restriction that you cannot<br>
> assign to an array A=f() and also do piecemeal assignments A[i]=g() .<br>
> We do track potential write accesses to arrays to keep them open until<br>
> there are no more possible writes.<br>
><br>
> <a href="http://www.mcs.anl.gov/exm/local/guides/swift.html#_arrays" target="_blank">http://www.mcs.anl.gov/exm/local/guides/swift.html#_arrays</a><br>
<br>
</div>That restriction should also be in swift/k, and I don't think it is.<br>
<br>
There is a problem with the current implementation. It fails to properly<br>
execute the following code:<br>
<br>
int[] a;<br>
<br>
if (true) {<br>
if (true) {<br>
a[0] = 1;<br>
}<br>
else {<br>
a[0] = 2;<br>
}<br>
f(a);<br>
}<br>
<br>
This is because a is closed in the scope in which it's declared, but<br>
that won't be done until f(a) completes, which it can't because a is not<br>
closed. That needs fixing. An additional complexity is that the<br>
following should also be allowed and function correctly:<br>
<br>
int[] a;<br>
<br>
if (true) {<br>
if (condition) {<br>
a[0] = 1;<br>
}<br>
f(a);<br>
}<br>
<br>
<br>
There's also the issue of:<br>
int[] a;<br>
<br>
foreach i in [0:10] {<br>
a[i] = 1;<br>
f(a);<br>
}<br>
<br>
That shouldn't be allowed. It is, and it leads to a deadlock.<br>
<br>
There are some subtleties:<br>
<br>
int[] a;<br>
if (true) {<br>
foreach i in [0:10] {<br>
if (true) {<br>
a[i] = 0;<br>
}<br>
else {<br>
a[i] = 1;<br>
}<br>
}<br>
f(a);<br>
}<br>
<br>
Closing of a can only happen after the foreach is done.<br>
<br>
All these cases need to be correctly handled by the compiler, and I<br>
think none of them are.<br>
<div><div><br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>