[Swift-devel] Problem with iterate

[Mihael Hategan]

On Fri, 2010-02-19 at 14:08 -0600, Ioan Raicu wrote:
> Yes, I think my confusion is coming from the fact that the order of
> statement in the source code is not preserved in the execution order
> (assuming there are dependencies). You are saying that the order in
> the source code doesn't matter in Swift. Perhaps this is what is
> making the analysis harder, to detect these deadlocks?

Yes it does. It's also necessary because it's what achieves
parallelization.

>  If Swift insisted on an ordering in execution, relative to the source
> code ordering, perhaps the analysis would be simplified? 

Right. The analysis of deadlocks is very much simplified in languages
that don't allow concurrency as Ben pointed out (i.e. deadlocks don't
exist, being replaced by infinite loops of one form or another).

a = f(1);
b = f(2);

If b is evaluated after a has a value (which would be the execution
order you suggest) then f(1) and f(2) would not be evaluated in
parallel.

> 
> My curiosity is mostly driven by trying to understand what assumptions
> in Swift is making this analysis hard to do, and how you would do
> things differently to help this kind of analysis be easier to do?

Right. Of course. But it turns out that you can't have everything and to
me it looks like deadlocks in a parallel languages is a problem of the
same class as the halting problem in non-parallel languages.

This is pretty much what the earlier emails in the discussion were
about.

That said, there are trivial cases, such as the a > b, b > a case that
can be detected quickly.