[Swift-devel] Changes to array closing semantics?

[Mihael Hategan]

On Wed, 2012-11-21 at 18:50 -0600, Tim Armstrong wrote:

> 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);
> }

It shouldn't deadlock. Nothing should. It just does in the current
swift/k implementation.

> 
> 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 don't know if I'd expect that if I wrote that code. Another
possibility is that I want f to be invoked successively with [1], [1,
1], [1, 1, 1], etc. So I don't think it's obvious what that code should
do, and I'd be inclined to have it forbidden. If the required behaviour
is f([10x1]) ten times, then the user can state that explicitly by
writing the equivalent code you mention.

> 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.

I'm guessing the total writer count is determined at run-time by
incrementing every time an iteration starts?

Can I steal that? I mean we favored doing this analysis statically in
swift/k, but I don't see why that should necessarily be the case.

>   There isn't an explicit runtime event corresponding to all
> statements in a block finishing.

Right. But if there was, it would be equivalent to the event of all
writes to a[] having been completed, at least in the case above. Here's
where it wouldn't:

foreach i in [0:10] {
   a[i] = 1;
   f(a[i]);
}

Which is why dynamic tracking would be better.

Mihael